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ABSTRACT 


VERT  HIGH-LEVEL  CONCURRENT  PROGRAMMING 

Yuan  Shi 

Supervisor:  Noah  Prywes 

Concurrent  systems  are  typically  large  and  complex,  requiring 
long  development  tine  and  euch  labor.  They  are,  therefore,  prime 
candidates  for  simplification  and  autoeiation  of  the  design  and 
programming  process.  Their  major  application  areas  include  real  time 
systems,  operating  systems  and  cooperative  computation  by  a  number  of 
independently  developed  geographically  dispersed  subsystems.  New 
applications  are  emerging  with  the  trends  towards  wide  usage  of 
personal  computers  connected  in  a  network  and  towards  use  of  parallel 
processing  in  supercomputer  architectures. 

The  prime  contribution  of  this  dissertation  is  the  creation  of  a 
programming  style  and  an  environment  that  allows  the  human  designers 
to  develop  an  implementation  independent,  very  high  level  functional 
view  of  the  concurrent  system^-  The  translation  of  this  view  into  a 
concurrently  operating  system  is  performed  automatically.  There  is  an 
emphasis  on  the  human  engineering  aspects  of  the  designer  -  computer 
interactions.  The  designers  specify  the  problem  through  declaring 
variable  structures  and  composing  equations  which  relate  the 
variables.  Thus  the  specification  is  entirely  declarative  and 
assertive,  without  reference  to  its  computerization.  The  designers 
partition  the  overall  specification  into  modules  which  are  each 
defined  independently.  These  modules  also  become  candidates  for  being 
computed  concurrently.  Each  module  consists  of  a  subset  of  the 
variable  declarations  and  equations.  The  designers  view  the 
concurrent  system  statically,  as  if  all  input  and  output  data  are 
available  a  priori,  and  the  equations  provide  mathematical 
relationships  among  the  data.  The  semantics  of  submitting  the 


specification  to  the  computer  is  to  have  the  computer  give  appropriate 
values  to  variables  that  all  the  equations  are  true.  Excluded  axe 
such  dynamic  implementation  concepts  as  sequences  of  program  events, 
synchronization ,  exchanges  of  messages  and  relative  timing.  To 
accomodate  the  large  size  of  typical  systems,  the  methodology 
supports  independence  in  specifying  and  testing  individual  modules. 
To  aid  debugging  and  attain  reliability,  language  processors  detect 
inconsistency  and  incompleteness  errors  in  both  the  individual  modules 
and  in  the  global  system.  The  translation  from  the  specification  into 
a  respective  computation  by  an  object  computer  architecture  is 
performed  by  the  language  processors.  The  entire  design,  prototyping 
and  simulation  of  a  system  can  be  performed  on  a  host  computer  and 
eventually  moved  to  an  object  distributed  computer  system  which  is  put 
into  productive  operation. 

The  dissertation  describes  an  investigation  of  this  approach 
using  as  the  object  computer  architecture  a  modem  distributed  system 
consisting  of  interconnected  sequential  processes,  each  operating 
under  a  multiprogramming  timesharing  operating  system. 

The  designers  of  a  concurrent  system  interact  with  automatic 
systems  on  two  levels:  On  the  global  level,  the  Configurator  accepts 
as  input  a  graph  of  the  network  of  subsystems,  modules  and  files.  Xt 
verifies  the  validity  of  interfaces  and  implements  the  network  by 
generating  coamand  language  programs  that  set  up  coamunications  and 
optimize  parallelism  among  modules.  The  modules  are  executed  under 
mult iprogr laming  time  sharing  operating  systems  in  respective 
sequential  processors  in  a  network. 

On  the  local  level,  the  MODEL  Compiler  accepts  as  input  an 
individual  module  specification.  Xt  performs  checking  of  completeness 
and  consistency  of  variables  and  equations  and  generates  an  optimised 
sequential  program  in  a  high  level  language  (PL/I)> 

The  above  two  systems  interact  in  Checking  the  integrity  of  the 
specified  system  and  generating  the  implementation  programs.  They 
have  been  implemented  in  PL/X,  in  the  environment  of  Digital's  VAX/VMS 
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operating  system.  Thus,  automatic  program  design  and  generation 
methodology  is  used  to  translate  the  very  high  level  specification 
into  an  efficient  customized  concurrent  computation  in  a  chosen 
environment. 

One  contribution  of  the  dissertation  of  the  dissertation  is  the 
exploration  of  the  generality  and  power  of  this  style  of  application 
systems  development.  This  style  of  programing  is  novel  and  there  has 
been  little  experience  with  it .  The  overall  methodology  is 
illustrated  through  two  characteristic  examples:  a  resource 
allocator,  widely  used  in  real-time  systems,  and  a  cooperative 
development  of  econometric  models  in  a  distributed  environment .  The 
exanples  present  the  new  style  of  programming. 

The  other  contributions  of  the  dissertation  are  in  the  solutions 
to  specific  concurrent  system  design  problems.  This  consisted  of 
employing  new  concepts  and  algorithms.  The  implementation  of  a 
specification  is  based  on  coamunication  of  messages  among  concurrent 
processes.  This  requires  checks  of  the  specification  to  alert  the 
designer  to  the  existence  of  inconsistencies  and  automatic  design  of 
implicit  synchronization  and  prevention  of  deadlocks.  The  entire 
concurrent  system  must  cooperate  in  the  distributed  computations, 
especially  in  initiation  and  termination  of  system-wide  iterative 
computations. 

The  dissertation  consists  of  three  parts.  Part  I  presents  the 
new  style  of  specifying  concurrent  systems,  as  well  as  high  level 
descriptions  of  automatic  design  and  programming  environment.  Part  II 
documents  the  design  of  the  Configurator,  part  III  documents  the 
modifications  to  the  previously  developed  MODEL  compiler  which  were 
necessary  for  concurrent  operation  of  programs  and  comminications 
among  the  programs. 
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INTRODUCTION 


1.1  THE  PROBLEM  AND  THE  OVERALL  APPROACH 


Concurrent  computation  ia  widely  used  in  operating  systems  and  in 
real  time  systems.  There  are  novel  application  areas,  such  as 
robotics,  which  require  coordination  of  a  number  of  activities.  It  is 
also  increasingly  used  in  distributed  processing  systems  for 
cooperative  computation  by  geographically  dispersed  users .  The 
greatest  potential  for  use  of  concurrent  computation  is  in  the 
emerging  parallel  computer  architectures  [Arvind,83;  Dennis, 80; 
Card,  82;  Smith, 78;  Treleavan,  82].  Programing  of  concurrent 
computing  has  proven  to  be  very  complex  and  prone  to  errors. 
Experience  indicates  that  it  consumes  enormous  amount  of  time  for 
program  development  and  maintenance.  The  difficulties  encountered  lie 
partly  in  the  large  size  of  typical  concurrent  systems,  but  more 
importantly  in  the  need  for  the  programmer  to  take  into  account 
sensitive  interactions  between  parallel  streams  of  program  events. 
For  these  reasons,  making  concurrent  programming  easier  has  received 
much  attention.  A  number  of  programming  languages  in  the  style  of 
conventional  high  level  languages  have  been  developed  [Brinch,  78; 
Hoars,  78;  Bolt,  78;  Milner,  80].  More  recently  a  new  type  of 
language,  variously  called  nonprocedural,  logical  or 
dataflow,  has  been  proposed  for  use  in  the  new  parallel  computer 
architectures  (Ackerman,  82;  McGraw,  82;  Hoffman,  82;  Arvind,  78; 
Ramamarithan,  83;  Backus,  78;  Shapiro,  83].  However,  in  these 


languages ,  the  programmer  still  needs  to  visualize  the  solution  of  the 
problem  in  terms  of  streams  of  data,  computations  by  processors  and 
comunications  among  processes.  This  level  is  considered  here  as 
still  too  low. 

A  very  high  level  approach  to  this  problem  is  described  in  this 
dissertation.  It  involves  use  of  a  mathematical  specification  of  a 
computation  which  does  not  require  operational  semantics.  It  consists 
only  of  declarations  of  structures  of  variables  and  equations  that 
relate  the  variables.  Such  a  specification  is  composed  without  regard 
to,  or  even  knowledge  of,  the  underlying  implementation  of  the 
computation .  The  translation  of  a  specification  into  a  computation  on 
an  abject  computer  architecture  is  performed  automatically.  The 
computer  architecture  selected  here  to  demonstrate  the  approach  is 
that  of  a  modem  distributed  processing  system  consisting  of 
interconnected  sequential  processors,  each  run  under  a 
multiprogramming  timesharing  operating  system.  The  translation  of  the 
specification  into  concurrent  programs  which  communicate  with  each 
other  is  performed  by  two  translating  systems:  a  Configurator  which 
implements  the  global  aspects  through  generating  command  language 
programs,  and  a  mope*.  Compiler  which  implements  the  local  aspects 
through  generating  high  level  language  programs  (PI/I)  for  individual 
processes.  The  translators  use  the  VAX/VMS  operating  system  and 
communication  facilities,  as  wsll  as  a  conventional  PL/I  programing 
language  compiler.  The  selection  of  the  VAX/VMS  environment  has  been 
purely  for  demonstrating  the  approach.  The  methodology  should  be 
equally  applicable  to  other  computer  architecture. 

The  above  two  translating  systems  offer  the  user  assistance  in 
debugging  and  validating  of  the  concurrent  system.  The  verification 
of  a  concurrent  system  poses  many  theoretical  and  practical  problems. 
Several  specification  languages  and  methods  have  been  proposed  for 
verification  of  concurrent  systems  [Zave,  94;  Lauer,  79;  Chen,  83; 
Pamas,  74;  Pnueli,  79].  Such  specifications  would  require  in 
typical  practical  applications  a  large  amount  of  labor.  Composing 


such  a  specification  is  also  prone  to  making  numerous  errors.  Also 
all-automatic  verification  is  not  possible  and  human  analysis  and 
assistance  is  necessary,  requiring  high  level  of  expertise  from  the 
user.  These  features  would  negate  our  abjective  of  reducing  labor  and 
user  expertise,  me  approach  here  requires  only  declarations  of  data 
structures  and  definitions  of  variables  by  equations.  Checks  were 
progressively  incorporated  in  the  Configurator  and  MODEL  Compiler,  for 
increasingly  complex  types  of  errors.  They  consist  of  checks  of 
compatibility  of  various  attributes  of  data  structures  referred  in 
equations  and  checks  of  respective  dependencies,  me  specification  is 
checked  for  consistency  of  use  of  data  types,  dimensionality  of  arrays 
and  ranges  of  dimensions.  Dependency  checks  include  the  completeness 
of  definitions  of  variables  and  analysis  of  circularity  of 
definitions.  Also  checks  are  conducted  of  some  rules  for  allowed 
dependencies.  me  above  Checks  have  been  incorporated  in  the  two 
translating  systems  and  their  effectiveness  was  evaluated 
experimentally  C Cheng,  83] .  An  important  consideration  in  reducing 
the  number  of  errors  is  that  the  user  employs  only  the  very-high-level 
view  and  thus  avoids  making  errors  in  the  impleamntation  level.  Also 
all  corrections  and  modifications  to  specification  are  done  in  the 
Configurator  or  MODEL  languages.  The  automatic  translators  employ  a 
variety  of  scheduling  and  communication  protocols  embodied  in 
operating  systems  and  ciawm inicat ions  technology,  which  have  been 
verified  and  of  which  the  user  need  not  even  be  aware. 

For  real  time  systems,  another  step  is  necessary.  Typically, 
real  time  systems  have  timing  constraints.  To  satisfy  the  time 
constraints,  a  designer  may  have  to  partition  a  module  into  several 
smaller  ones  based  on  the  estimated  execution  time  produced  at 
compilation  time.  A  system  for  obtaining  the  needed  timing 
information,  based  on  the  module  specifications,  is  being  developed 
(Tseng,  83]. 

The  dissertation  describes  a  very-high  level  language  for 
concurrent  programing  which  is  devoid  of  implementation  aspects  and 


it  explores  the  effectiveness  of  programing  with  such  a  language 
(assisted  by  the  two  translators).  It  also  describes  the  operation  of 
the  two  translators  -  the  Configurator  and  MODEL  compiler  -  with 
emphasis  on 

i)  semantic  checking  of  the  very-high- level  language  input  and 
assisting  the  user  in  its  composition, 

ii)  optimization  of  the  overall  computation  by  use  of  parallelism  to 
reduce  overall  execution  time  and  by  minimizing  the  use  of  main 
memory  storage  and  computation  time  in  individual  processors. 

1.2  CONTRIBUTIONS 

The  objectives  and  contributions  of  the  dissertation  are  as 
follows. 

i)  devising  a  very-high  level  language  for  concurrent  programming 
which  is  devoid  of  implementation  aspects. 

ii)  exploring  the  effectiveness  of  programing  with  such  a  language 
( illustrated  by  two  examples ) 

iii)  devising,  demonstrating  and  exploring  the  operation  of 
translators  of  the  very-high  level  languages  into  am 
implementation  of  the  computation  in  the  object  computer 
architecture,  with  emphasis  on 

a)  semantic  checking  of  the  very-high- level  language  input  and 
assisting  the  user  in  its  composition, 

b)  optimization  of  the  overall  computation  by  use  of  parallelism 
to  reduce  overall  execution  time  and  by  minimizing  the  use  of 
main  memory  storage  and  computation  time  in  individual 
processors. 

The  dissertation  endeavors  to  make  two  points: 
i)  that  very  high  level  definitional,  nonprocedural,  dataflow 


languages  can  be  used  very  effectively  and  naturally  in 
concurrent  programming,  and 

ii)  that  automatic  design  and  program  generation  methodology  can 
support  program  development  and  generate  an  efficient 
implementation  of  the  concurrent  system. 


1.3  PRINCIPAL  CHARACTERISTICS  OF  THE  VERY-HIGH  LEVEL  LANGGACZ 

The  principal  characteristics  of  the  proposed  programming  style, 
which  distinguish  it  from  conventional  programming  are  summarized 
below. 

i)  An  overall  specification  is  partitioned  into  modules .  The.  user 
prepares  a  specification  for  each  module.  A  specification  of  a 
module  consists  of  declarations  of  -variable  structures,  equations 
that  define  output  variables  in  terms  of  input  variables,  and 
declarations  of  external  dependencies  of  input  variables  on 
output  variables.  An  external  dependency  declared  in  one  module 
indicates  that  a  function  is  specified  in  detail  in  other 
modules.  A  user  engaged  in  composing  a  specification  has  to 
state  whether  an  external  dependency  exists,  but  does  not  have  to 
know  the  detailed  definitions  involved  in  the  dependency.  Thus  a 
specification  of  a  module  becomes  independent  of  other  modules. 

ii)  A  variable  in  a  specification  may  assume  only  one  value.  This  is 
similar  to  the  approach  taken  in  mathematics.  This  means  that 
all  the  values  evaluated  in  the  eventual  computation  procedural 
program  are  represented  in  the  high  level  view  by  distinct 
variables.  This  allcars  the  user  to  view  all  input,  interim  and 
output  variables  statically,  as  if  they  assumed  values  a  priori, 
and  helps  to  compose  equations  that  express  the  relationships 
among  the  variables. 

iii )  Specification  statements  may  be  in  an  arbitrary  order  and  there 
are  no  control  statements ,  such  as  for  input-output,  iterations. 


etc.  The  user  visualizes  the  specification,  not  as  a  set  of 
comnands  to  be  performed  by  a  computer  -  as  in  conventional 
programing  languages  -  but  as  a  set  of  equations  that  should  be 
made  true,  by  finding  the  appropriate  values  for  variables. 
Thus,  every  equation  is  am  "invariant"  assertion. 

iv)  The  synthesis  of  modules  into  a  global  system  is  specified  in  a 
configuration  language.  Modules  and  files  are  assembled  into  a 
configuration  by  defining  a  dataflow-like  graph  -  with  modules, 
subsystems  and  files  as  the  nodes  and  their  input-output 
relationships  as  the  edges.  A  configuration  may  itself  be  a 
subsystem  represented  by  a  node  in  a  higher  level  configuration. 
The  evaluation  of  a  configuration  means  making  all  the  modules 
true  (meaning  that  all  the  equations  in  the  respective  module 
specifications  are  true).  Thus  a  configuration  is  viewed  as  a 
static  description  of  a  computation,  similar  to  individual 
modules. 

v)  The  user  is  not  concerned  with  optimizing  efficiency  of 
computations.  The  automatic  translators  incorporate  optimization 
for  efficiency.  They  examine  the  efficiency  of  a  much  larger 
number  and  variations  of  possible  computation  schedules  than  a 
human  programmer  could  possibly  conceive  and  consider.  Further, 
the  user  would  have  to  be  highly  expert  in  the  object  computer 
architecture  in  order  to  offer  guidance  on  efficiency.  The  one 
exception  to  this  approach  is  where  the  user  determines  the 
partition  of  the  overall  specification  into  modules  which  the 
translators  may  schedule  concurrently. 

Parallel  execution  of  recursive  functions  have  not  been  included 
in  the  translators  described  here.  Because  of  the  recent  interest  in 
parallel  execution  of  recursive  functions  in  artificial  intelligence, 
an  extension  to  the  system  for  dynamic  initiation  of  recursive 
definitions  is  considered  for  future  research. 
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FIGURE  1.  Schematic  Diagram  of  Concurrent  Programming  Procedure 


1.4  PROGRAM  DEVELOPMQPT  PROCEDURE 


The  overall  procedure  in  using  this  methodology  is  illustrated 
schematically  in  Figure  1.  It  starts  (at  the  top)  with  existence  of  a 
concurrent  programing  problem.  In  the  case  of  a  top-down  approach, 
the  human  users  have  to  partition  the  problem  into  modules.  In  a 
bottom-up  approach,  the  modules  may  already  exist.  There  are  two 
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parallel  paths  in  Figure  1  for  module  definition  and  for  global  system 
synthesis.  They  merge  at  the  bottom  of  the  diagram  to  produce  the 
concurrent  computation.  The  order  of  employing  these  two  paths 
depends  on  whether  a  top-down  or  a  bottom— up  approach  is  undertaken. 

The  path  on  the  left  is  followed  for  each  module  in  a 
configuration.  In  case  of  system  modification,  only  the 
specifications  of  affected  modules  need  to  be  added,  deleted  or 
changed.  This  path  consists  of  composing  a  specification  of  a  module 
in  the  MODEL  language,  and  submitting  it  to  the  MODEL  Compiler.  The 
MODEL  Compiler  constructs  a  dataflow  graph  for  the  module 
specification.  This  graph  is  used  for  analysis  of  consistency  and 
completeness  of  definitions,  to  discover  errors,  and  for  optimization 
of  the  generated  program.  The  user  musv  then  make  corrections  to 
respond  to  error  and  waning  messages  issued  by  the  MODEL  Compiler. 
Finally,  a  program  is  generated,  in  our  case  in  PL/ I .  The  program  can 
then  be  executed  as  a  process,  by  itself  for  testing,  and  in 
concurrent  operation  with  other  modules  as  described  in  a 
configuration  specification. 

The  path  on  the  right  of  Figure  1  is  used  to  integrate  programs 
into  a  concurrent  computation .  A  specification  of  a  network  of 
modules  and  files  is  submitted  to  the  Configurator.  The  Configurator 
constructs  a  dataflow  graph  of  the  configuration  and  analyzes  the 
graph  for  compatability  of  the  interconnections  and  completeness.  The 
user  must  make  appropriate  changes  to  respond  to  error  or  warning 
messages.  The  Configurator  produces  then  an  overall  customized  design 
to  maximize  the  parallelism  in  execution  of  modules,  and  generates  a 
set  of  comnand  language  programs  for  executing  the  network  of  modules 
in  a  chosen  environment  of  computers,  conmunications  and  their 
operating  systems.  The  Configurator  also  performs  system  wide 
documentation ,  similar  to  previously  developed  systems  [Teichreow, 
771. 


l.S  ASSUMPTIONS 


A  number  of  constraining  assumptions  ware  made  to  permit  the 
implementation  of  the  Configurator  and  MODEL  compiler  using  the 
existing  hardware/ software  systems .  They  also  define  the  application 
domain  of  the  developed  system. 

The  assumptions  of  the  developed  systems  are  listed  as  follows: 

i )  Hardware/Software  Environment 

The  physical  environment  assumed  is  a  computer  network, 
where  each  node  consists  of  one  or  more  sequential  computers  that 
operate  under  multi-prograimning  operating  systems.  The  operating 
systems  must  have  a  file  system  for  handling  sequential,  indexed 
sequential  and  mailbox  files. 

ii)  Each  module  or  file  is  assigned  to  a  specific  location  in  the 
computer  network.  Changes  in  location  require  re-specify  the 
configuration . 

iii)  It  is  up  to  the  user  to  define  backup  modules  and  files.  Namely, 
the  user  must  define  backup  files  and  recovery  modules  manually. 
The  systems  does  not  automatically  incorporate  such  operations. 

iv)  NO  recursive  module  definition  is  allowed.  This  is  restricted  by 
the  inability  of  dynamically  creating  modules.  However,  modules 
can  be  activated  dynamically  by  addressing  messages  to  them. 
Also,  using  the  developed  systems,  i.e.  the  CONFIGURATOR  and  the 
concurrent  MODEL  compiler,  recursion  can  be  simulated 
iteratively. 

The  above  assumptions  implicitly  restrict  the  scope  of  the 
research  area  and  the  application  domain  of  the  developed  systems. 
For  instance ,  dynamic  module  re-allocation  is  not  addressed  in  this 
dissertation.  Also,  besides  saving  wrongly  addressed  messages,  the 


developed  systems  do  not  support  failure  recovery  services 
automatically . 

1.6  USE  OP  EXAMPLES 

The  style  of  programming  here  differs  greatly  from  that  of 
conventional  procedural  programming .  The  dissertation  focuses  on 
presenting  the  new  style  through  two  examples.  The  first  example  is 
of  a  resource  allocator,  such  as  found  in  operating  systems  or  in  real 
time  systems.  This  example  uses  a  top-down  approach,  where  the 
overall  system  is  partitioned  first  and  then  individual  modules  acre 
specified.  The  second  example  illustrates  cooperative  computation  in 
a  distributed  processing  environment.  It  consists  of  econometric 
models  for  a  group  of  countries  that  are  linked  together  to  form  a 
regional  econometric  model.  This  example  stresses  a  bottom-up 
approach  -  developing  or  modifying  first  the  individual  modules 
followed  by  their  synthesis.  The  operation  of  the  two  translators  is 
described  only  generally  in  the  interest  of  brevity.  The  further 
detail  of  the  examples  are  given  in  Appendix  A. 


1.6.1  RESOURCE  ALLOCATION 

Resource  allocation  captures  the  essence  of  many  concurrent 
systems  used  in  real-time  applications.  It  is  used  in  operating 
systems  to  allocate  computing  and  input-output  resources  to  jobs,  and 
in  real-time  systems  to  allocate  available  resources  to  participants  - 
such  as  routes  and  landing  permissions  in  an  air  traffic  control 
system.  To  simplify  the  example,  only  reusable  resources  are 
allocated.  Allocation  of  consumable  resources  is  illustrated  in  the 
second  example.  There  are  many  strategies  for  allocating  resources. 
The  more  complex  ones  use  resources  more  efficiently  and  fairly  while 
preventing  a  deadlock.  Again  for  simplicity,  the  strategy  selected 


here  avoids  deadlocks  by  requiring  that  a  module  submit  a  naaciam 
«n  request  for  all  the  resources  that  it  will  need,  and  release 
them  when  not  further  needed .  Also  to  satisfy  the  fairness 
requirement,  requests  aura  satisfied  in  strict  order  of  aurrival . 

To  make  the  example  more  specific  and  easier  to  follow  it  is 
stated  in  terms  of  the  Dining  Philosophers  problem  as  related  by 
[Hoare,  78]  due  to  E.  W.  Dijkstra.  This  however  does  not  restrict 
the  generality  of  the  example.  Five  philosophers  share  a  circular 
dining  table  where  each  has  an  assigned  seat.  There  is  one  fork 
between  each  two  seats.  A  philosopher  needs  the  forks  to  his  right 
and  left  in  order  to  dine.  A  philosopher  desiring  to  dine  requests 
the  forks.  When  available,  the  resource  allocator  issues  both  forks 
aund  the  philosopher  proceeds  to  dine.  When  finished,  he- releases  both 
forks,  which  became  available  to  his  inmediate  neighbors  on  a 
first-come— first-allocated  basis. 


1.6.2  COOPERATIVE  PROGRAMMING 

Concurrent  programming  has  been  considered  in  the  past  mainly  as 
a  top-down  development  process,  outlining  first  the  global  aspects  and 
then  proceeding  to  fill  in  the  local  details .  With  the  advent  of 
computer  technology,  the  price  of  computers  has  drastically  declined 
and  the  computation  power  available  in  the  past  only  in  large  scale 
"main-frames"  has  become  available  in  small  personal  computers.  This 
is  bound  to  enhance  connecting  local  computers  to  integrate  many 
complementary  computations  which  were  developed  independently.  This 
node  of  activity  has  been  called  cooperative  computation .  In  this 
mode,  definitions  of  local  modules  occur  naturally  reflecting  the 
interest  and  expertise  of  local  developers.  The  developers  axe 
typically  initially  uncoordinated  and  dispersed  organizationally  and 
geographically .  The  motivation  for  linking  computers  with  modules  and 
data  into  am  integrated  system  comes  later,  based  on  recognition  of 


the  interdependence  of  the  respective  problem  areas .  The  advantage  in 
synthesizing  a  global  system  may  be  viewed  as  follows.  In  an  isolated 
module,  the  variables  which  are  imposed  by  the  external  environment 
are  considered  as  parameters  and  their  values  are  assumed  by  the  user. 
In  contrast,  in  a  globed,  system  these  variables  can  be  jointly 
evaluated,  which  makes  the  results  much  more  reliable.  The  mean 
difficulty  in  synthesizing  a  number  of  modules  is  frequently  due  to 
the  difference  in  definitions  given  to  essentially  common  variables  in 
independently  developed  interacting  modules.  An  agreement  must  be 
made  between  authors  of  such  modules  on  needed  trams formations  of 
these  variables  to  obtain  a  cannon  meaning  and  structure.  Such  an 
agreement  is  called  a  contract  [Gana,  78]  and  is  sometimes  defined  by 
adding  an  interfacing  module  which  performs  the  translation. 

Project  LINK  [Klein,  77]  is  a  classical  example  of  cooperative 
computation  and  is  used  here  as  an  illustration.  It  consists  of  a 
number  of  institutions  who  have  been  developing  stand  alone 
econometric  models,  typically  for  their  own  country  or  region,  and  who 
cooperate  in  synthesizing  their  models  into  an  area  or  world  wide 
model.  The  databases  and  econometric  equations  in  the  local  models 
are  in  constant  flux  due  to  political  and  economic  changes.  Since  the 
respective  economies  are  highly  interdependent,  it  is  very  important 
to  synthesize  the  models  to  evaluate  the  effect  of  the  very  latest 
developments .  The  synthesis  of  models  is  frequently  performed  on  an 
ad-hoc  basis.  Also  results  must  be  obtained  quickly  to  alert  the 
decision  makers  to  needed  changes  in  economic  policies  and  plans. 

The  second  example  has  been  proposed  to  us  by  Y.  Yasuda  of  Kyoto 
University  and  of  the  staff  of  the  LINK  Project  at  the  university  of 
Pennsylvania.  It  consists  of  a  study  of  economic  interactions  in  the 
Pacific  Basin.  The  economies  studied  and  their  corresponding  models 
are  those  of  the  USA,  Japan,  Taiwan,  Korea,  Philippine  and  Thailand . 


1.7  RELATED  WORK 


In  proposing  a  nonprocedural  approach  for  specification  and 
implementation  of  a  concurrent  system,  we  are  following  in  the 
footsteps  of  a  number  of  proposed  languages  for  concurrent 
programing . 

The  proposed  language,  however,  is  drastically  different  in  its 
semantics  from  previously  developed  programming  languages.  It 
essentially  requires  composing  data  objects  and  their 
inter-relationship  mathematically  and  the  compiler  will  make  all  the 
definitions  became  true. 

1.7.1  CONCURRENT  PROLOG 

PROLOG  is  a  "tree"  structured  language.  Each  axiom  is  expressed 
and  evaluated  in  a  tree  fashion  with  the  answer  at  the  top  of  the 
tree.  In  sequential  PROLOG,  the  evaluation  of  the  tree  is  depth-first 
and  from  left-to-right .  The  main  idea  of  designing  concurrent  PROLOG 
is  to  explore  the  use  of  concurrency  implied  in  "AND"  and  "OR"  nodes 
in  the  tree.  Each  node  in  the  tree  can  communicate  with  each  other 
through  passing  messages.  Since  the  message  passing  mechanism  really 
bears  the  concept  of  dataflow,  the  concurrent  PROLOG  has  a  quite 
different  programing  style  than  sequential  PROLOG,  it  has  been  called 
"object  oriented  programming"  [E. Shapiro,  83]. 

MODEL  is  not  a  tree  structure  language.  It  uses  the  syntax 
similar  to  the  notions  used  in  algebra.  Modules  are  defined  by  the 
user  at  a  higher- level .  The  user  of  the  MODEL  language  does  not  "see" 
messages  passing  between  modules.  He  sees  only  differently  organized 
entire  files  being  produced  and  consumed  by  modules.  The  user  also 
does  not  see  the  concurrency  explicitly.  It  is  up  to  the  Configurator 
to  decide  the  concurrency  of  the  overall  system.  Of  course,  the  more 
the  modules  are  being  partitioned,  there  are  more  candidates  to  be 
computed  concurrently. 


A. 


1.7.2  MODULARITY  IN  UNIX 


Kemighan  [84]  points  out  the  added  dimension  of  modularity 
offered  by  connecting  processes  to  form  an  integrated  system  (as  an 
alternative  to  procedure  modularity).  He  discussed  the  effectiveness 
of  this  mode  of  modularity  when  using  UNIX.  In  UNIX,  there  is  a 
mechanism  called  "pipeline"  which  can  be  used  to  construct  bigger  and 
complex  programs  by  connecting  small  and  simpler  processes.  A 
"pipeline"  is  a  message  channel  between  processes. 

In  MODEL,  the  devices  similar  to  a  "pipeline"  are  the  MAIL  and 
POST  files,  the  MAIL  and  POST  files  offer  much  greater  flexibility  in 
communications  between  modules,  including  1  to  many  and  many  to  1 
distribution  of  messages.  It  therefore  further  enhances  this  mode  of 
attaining  modularity. 

1.7.3  DATAFLOW  MACHINES 

Using  the  currently  developed  Configurator  and  the  MODEL 
compiler,  the  concurrency  of  an  application  system  is  purely  on  the 
module  level.  It  is  based  on  the  partitioning  of  the  overall 
specified  application  system.  There  is  no  concurrency  below  the 
module  level,  because  the  MODEL  compiler  generates  a  sequential 
program  for  each  module  specification.  'Riis,  however,  is  not  a 
limitation  of  the  proposed  approach,  the  MODEL  compiler  could  equally 
well  produce  parallelism  within  each  module.  Maya  Gokhale 
[G6khale,83]  demonstrated  how  to  directly  translate  a  MODEL 
specification  into  MAD,  a  low-level  dataflow  language  designed  for  the 
Manchester  dataflow  machine.  Thus  an  integrated  dataflow  system  is 
feasible  by  using  the  Configurator  (at  high-level)  and  Gokhale ' s  MODEL 
compiler  (at  lower- level)  to  operate  a  cluster  of  dataflow  machines 
concurrently. 

1.7.4  SURVEY  OF  OTHER  CONCURRENT  PROGRAMMING  LANGUAGES 


Historically,  concurrent  programming  languages  used  either 
message  passing  or  shared  memory  for  inter-module  ccnmunication .  This 
approach  required  analysis  of  the  timing  and  waiting  patterns  of  the 
global  computation  events.  This  contrasts  with  the  use  of  files  for 
inter-module  coosunication  which  eliminates  lower-level  timing 
considerations . 

•Concurrent  Pascal  (Hansen,  77] 

A  concurrent  programming  language  based  on  the  MONITOR 
concept  and  emphasising  structured  programming  for  concurrent 
program.  More  recently,  a  new  version  of  concurrent  Pascal 
(EDISON)  (Hen sen,  81]  was  developed.  In  EDISON,  a  new  mechanism 
supporting  abstract  data  type  is  implemented.  Use  of  this 
language  can  produce  more  structured  and  modularized  program 
than  its  ancestor. 

The  MONITOR  concept  requires  shared  memory  hardware  and  is 
not  readily  usable  in  distributed  processing.  However,  the  basic 
concept  of  a  MONITOR  for  resource  allocation  can  be  expressed  in 
MODEL  as  illustrated  in  the  resource  allocation  example  ( Chapter 
4). 

•Communicating  Sequential  Processes  (CSP)  (Boare,  78  and  81], 

A  concurrent  programing  language  using  message  passing 
which  combines  the  guarded  command  suggested  by  Disjkstra  and 
parallel  composition  of  processes .  It  uses  only  primitive 
message  send  and  receive  constructs.  The  intention  of  creating 
this  language  was  to  provide  a  formalism  for  concurrent 
programing. 

•Concurrent  SP/Jc  (CSP/k)  (Holt  et  al,  78] 

An  extension  to  PL/I  for  structured  concurrent  programing 
also  based  on  the  MONITOR  concept. 


•Concurrent  AND/OR  Programs  (CA0P)  [Harel  and  Nehab,  82]. 

A  functional  concurrent  specification/programing  language 
which  utilises  recursive  functions.  CA0P  can  be  considered  as 
non-procedural.  However,  cc—unication  is  still  expressed  in 
terms  of  individual  messages.  It  resembles  concurrent  PROLOG  in 
many  aspects.  The  computation  model  of  this  language  adopts  the 
basic  concepts  suggested  by  Milner  for  CCS. 

•ADA  programming  language  [Ledgaxd,  80], [Taylor,  83] 

A  general  purpose  programming  language  for  computer  embedded 
systems  which  typically  require  concurrency  and  real  time 
operation  [Ledgard,  80].  The  primary  interprocess  interaction  is 
termed  "rendezvous" .  A  "rendezvous'*  is  a  match  of  named  entries 
called  by  one  task  and  declared  in  another  task,  a  "rendezvous" 
is  completed  when  a  process  executes  an  ACCEPT  statement  in  the 
callee.  The  major  concurrent  computation  description  in  ADA  is 
thzou^i  TASK  description.  According  to  [Hil finger,  82],  this  is 
an  unnecessary  complication  to  the  language  and  may  be  well 
defined  by  the  existing  TCTE  mechanism  in  ADA.  Structured 
prograimning  technique  is  encouraged  by  the  language  design.  Also 
efforts  to  verify  the  correctness  of  ADA  programs  have  been  made 
[Taylor,  83]. 

•Specifying  Concurrent  Program  Modules  [Lamport,  83] 

A  specification  method  intended  to  specify  the  properties  of 
concurrent  systems( safety  properties  and  liveness  properties) 
using  intuitive  temporal  logic  notions  and  power  domain 
construction.  There  is  some  similarity  between  this  method  and 
the  one  proposed  here  since  both  approaches  require  making 
assertions  about  the  data  rather  than  describing  the  behavior  of 
the  processes. 

•Calculus  of  Coaanunicating  Systems  (CCS)  [Milner,  80]. 


A  calculus  of  describing  mathematical  models  for  processes 
and  observable  behavior  of  a  concurrent  system  based  on  the 
notion  of  "flow  algebra"  [Milner,  79].  The  objective  was  that 
the  proof  techniques  for  reasoning  concurrent  sequential 
processes  could  be  fully  developed  in  CCS.  The  concept  "behavior 
observation"  in  CCS  has  been  adopted  in  PPL,  CAOF,  and  other 
systems. 

*PAISLey,  Executable  requirements  for  embedded  systems  [Zave,  1962] 

The  result  of  the  execution  of  a  PAISLey  specification  is  a 
set  logical  consequences  derived  from  the  specification.  It  is  a 
language  to  record  the  requirements  in  a  system  (including 
supporting  system  and  application  system)  in  a  formal  way.  It  is 
not  intended  to  be  a  "design  specification"  language,  namely  is 
not  intended  to  really  Implement  any  actual  algorithms. 

*PPL>  A  Functional  Language  for  Parallel  Programing  [Holmstrom.S. 
83] 

A  parallel  functional  programming  language  with  the 
intention  of  formal  description  of  concurrent  programs.  It  is 
built  on  the  top  of  an  existing  functional  programming  language 
ML.  It  adopts  some  concepts  from  CCS,  such  as  "Channel"  and 
"behavior".  The  new  extension  of  the  concurrent  part  inherits 
the  rigour  of  ML  system.  It  uses  "typed  channels"  and  models  the 
Imperative  part  of  the  language  very  carefully  (the  I/O  part)  by 
using  continuation  in  denotational  semantics.  It  is  claimed  by 
the  author  that  PPL  is  more  general  than  CCS  but  more  difficult 
to  reason  about  formally  and  informally.  # 

*0N  THE  RELATIONSHIP  OP  CCS  AND  CSP  [Stephen  D.  Brookes,  1983] 

This  article  addresses  the  relationship  between  the  failure 
model  proposed  for  CSP  and  the  synchronization  tree  model  for 
CCS.  It  finds  a  suitable  set  of  axioms  for  the  failure 
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equivalence  relation  (similar  to  Milner's  observation 
equivalence).  This  work  reveals  the  similarity  in  the  underlying 
semantic  models  of  CCS  and  CSP. 

* ARGUS:  THE  PROGRAMMING  LANGUAGE  AND  SYSTEM  [LiskOV,  83,84] 

A  programming  language  and  compiler  designed  to  solve 
failure  and  recovery  problems  in  distributed  computing.  The  two 
mechanisms,  GUARDIAN  and  ACTION  (two  abstract  datatypes)  are  used 
for  implementing  surviving  services  for  system  failure.  The 
approach  is  based  on  ATOMICY  of  program  units. 

More  thorough  surveys  of  models  and  programming  languages  for 
concurrent  computation  can  be  found  in  [D.B.  MacQueen,  1979]  and 
(G.R.  Andrews,  1983]. 


1.8  ORGANIZATION  OF  THE  DISSERTATION 


The  dissertation  is  organized  in  the  following  way. 


HIGH-LEVEL  CONCURRENT  PROGRAMING 

I 

v 


GENERAL  DESCRIPTION 
AND  EXAMPLES 


-t- 


IMPLEMENTATION 


v 


CONFIGURATOR  MODEL 


V 

PART  I 


v 

PART  II 


v 

PART  III 


RESULTS 


APPENDIXES 


In  Part  I,  the  style  of  the  high-level  concurrent  programming  is 
presented  by  giving  two  characteristic  examples  of  concurrent 
programming.  Also  overall  description  of  the  design  of  the  two 
developed  systems  and  the  major  problems  solved  during  the  development 
are  all  included. 


The  material  in  Parts  II  and  III  presents  the  methods,  algorithms 


and  techniques  used  in  the  implementation  of  the  Configurator  and 
MODEL  compiler,  respectively.  The  algorithms  used  in  implementation 
aura  given  with  estimated  complexity.  Reading  of  Part  ri  and  III  is 
not  necessary  if  only  understanding  of  the  general  ideas  is  desired. 

In  order  to  let  the  interested  reader  examine  the  working 
environment  of  the  two  systems  in  even  greater  detail,  actual 
input/output  of  the  two  systems  are  provided  in  the  appendixes.  Also, 
for  the  sake  of  completeness,  the  syntax  descriptions  of  the  two 
languages  ( CSL  and  MODEL)  are  given  in  Part  II  and  Appendix  B 
respectively. 


CHAPTER  2 

COMPOSING  A  CONFIGURATION  OP  MODULES  AND  PILES 

2.1  MODULES  AND  PILES 

A  user  composes  a  concurrent  system  by  specifying  a  configuration 
of  modules  and  files .  The  optimal  partitioning  of  an  overall 
specification  into  concurrent  modules,  to  obtain  low  computation  time, 
is  still  an  open  problem.  Therefore  typically,  boundaries  of  modules 
are  defined  along  functional  divisions.  The  user  considers  each 
module  independently  in  isolation.  Therefore  he  regards  the  outside 
environment  purely  as  data  files.  Such  files  can  connect  modules  in 
the  overall  configuration.  Subsystems  are  subconfiguration  defined 
separately.  In  our  example  of  resource  allocation,  the  five 
philosophers  and  the  resource  allocator  form  respective  modules 
naturally.  Modules  are  consumers  or  producers  of  their  source  or 
target  files,  respectively. 


2.2  CONFIGURATION  OP  THE  DINING  PHILOSOPHER  EXAMPLE 

The  configuration  for  the  Dining  Philosophers  is  shown  in  Figure 
2 .  Each  philosopher  module  ( Pi  to  PS )  produces  a  file  of  requests  and 
releases  of  resources  ( REQ  REL )  and  consumes  a  file  of  allocations  of 
resources  (ALL0C1  to  ALLOCS).  The  resource  allocator  (R)  has  a  target 
file  of  allocations  (ALLOC)  and  a  source  file  of  requests  and  releases 
of  resources  ( REQ  REL ) .  a  target/ source  or  consumer/producer 
relationship  is  represented  by  a  directed  edge  in  the  network.  When 
the  same  file  is  produced  by  one  module  and  consumed  by  another  module 
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!  ATiijQci  i 
I  (MAIL)! 


| ALL0C2 | 
I(MAIL)| 


|  ALL0C3 1 
|  ( MAIL ) | 


| ALLOC4| 
I ( MAIL ) ! 


{ALLOCS!  ! 
! ( MAIL ) j  | 


REQ_REL  !  <- 
(MAIL)  | 


FIGURE  2.  Configuration  Network  For  Reusable  Resources 
Allocation  Example 


The  user  must  select  the  attributes  of  connecting  files  and  in 
this  way  provide  information  for  guiding  the  Configurator  in  attaining 
high  degree  of  concurrency  in  the  computation.  The  descriptions  of 
the  organization  of  a  file,  given  in  the  specifications  of  it's 
producer  and  consumer  modules,  must  be  compatible.  For  example,  as 
will  be  shown  later,  the  target  file  of  the  resource  allocator  (ALLOC) 
and  the  source  files  of  the  philosophers  ( ALL0C1 , . . . )  contain  the  same 
data  but  are  viewed  by  their  producer  and  consumer  modules  as  having 
different  organizations.  The  file  compatibility  rules  are  are  stated 
later  as  some  knowledge  of  the  MODEL  language  (described  in  Chapter  5) 
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is  necessary. 

TOius  the  user  must  instruct  the  system  about  the  nature  of  module 
and  file  nodes.  A  module  may  be 

i)  an  individually  specified  module  ( MDL-de fault ) , 

ii)  a  group  of  modules  and  files  that  form  a  subsystem  which  is 
defined  in  a  separate  configuration  (GRP),  or 

iii)  a  human  with  an  interactive  terminal  communicating  with  the 
system  (MAN).  This  type  of  "module"  naturally  is  not  initiated 
automatically . 

As  noted,  the  user  regards  files  as  aggregates  of  static  data  and  must 
therefore  specify  the  organization  of  the  data  as  follows. 

i)  Sequential  (SAM-default):  The  sequential  file  is  being 

couminicated  as  one  entity.  •  It  implies  that  the  file  can  be 
consumed  only  after  it  has  been  entirely  produced.  Such  a  file 
may  have  only  one  producer  module,  but  any  number  of  consumers. 
It  is  typically  associated  with  a  device,  such  as  tape,  printer. 


ii )  Index-sequential  ( ISAM ) :  Each  record  in  an  index-sequential  file 
has  a  variable  defined  as  a  key  which  defines  (accesses)  a  record 
in  the  file .  There  are  no  restrictions  on  the  order  of 
references  to  such  a  file  by  producer  or  consumer  modules.  If 
only  a  single  record  can  be  updated  at  a  time,  then  the  MODEL 
Compiler  incorporates  code  in  the  generated  programs  to  lock  each 
other  when  updating  the  critical  data.  Otherwise,  the  user  is 
notified  and  control  of  access  must  be  part  of  the  system 
specification  ( similar  to  the  resource  allocator  example ) .  The 
user  can  also  indicate  that  an  ISAM  file  is  first  produced  and 
later  consumed.  In  such  a  case  the  user  has  to  define  separate 
old  and  new  versions  of  the  file  and  denote  an  edge  between  the 
two  versions  in  the  configuration.  An  ISAM  oganization  file  is 
typically  associated  with  a  disk  device. 


ill)  A  mailbox  (MAIL):  A  mailbox  file  can  have  a  number  of  producer 
and  consumer  modules.  Records  from  different  producers  are 
queued  in  a  nail  file  until  consumed  in  order  of  their  arrival. 
If  there  are  more  than  one  consumer,  they  consume  the  queued 
records  in  an  arbitrary  order.  Thus  it  is  not  necessary  to  have 
a  physical  device  for  storing  a  nail  organized  file, 
iv)  Post  office  like  facility  (POST):  A  post  file  is  a  distributor 
of  records  to  other  ( source )  mailbox  files .  It  hats  one  producer 
module,  and  its  records  include  a  variable  defined  as  an  address 
of  a  destination  MAIL  file.  Therefore,  it  can  have  any  number  of 
edges  connecting  it  to  mail  files. 

MAIL  and/or  POST  file  organizations  are  used  for  direct 
connection  of  files  between  modules  without  the  use  of  intermediate 
storage  device.  The  producing  and  consuming  may  then  be  concurrent. 

The  POST  and  MAIL  files  use  limited  space  in  main  memory.  The 
MODEL  Compiler,  when  generating  a  program  for  a  module,  optimizes  the 
use  of  main  memory  space  used  for  data  in  these  files.  Program 
optimization  causes  a  producer  module  to  store  and  produce  one  or  a 
few  records  at  a  time  and  the  consumer  module  to  consume  and  store  one 
or  a  few  records  at  a  time  ( if  possible ) .  If  producer  and  consumer 
processes  are  concurrent,  the  POST  or  MAIL  facilities  need  to  buffer 
only  a  limited  number  of  records.  This  is  similar  to  the  concept  of  a 
pipeline  or  a  stream.  Such  a  file  is  referred  to  in  the  following  as 
having  a  virtual  dimension  along  which  only  a  window  of  records  needs 
to  be  buffered.  The  user  is  not  involved  in  program  design,  but  is 
told  that  to  attain  better  efficiency  only  certain  forms  of  subscript 
expressions  may  be  used  in  referencing  variables  such  files.  A 

specifier  of  a  module  is  advised  by  warning  messages  if  other 
subscript  expression  forms  were  used  and  whether  a  file  dimension  can 
or  can  not  be  virtual.  This  is  further  discussed  later. 


The  above  rules  must  be  followed  in  connecting  modules  and  files 
into  a  configuration.  A  configuration  network  is  shown  in  Figure  2 
for  the  resource  allocation  example.  The  language  used  to  specify  a 
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configuration  consists  of  statements  that  define  paths  in  the  network. 
Figure  3  shows  the  specification  for  the  configuration  of  Pigure  2.  A 
statement  of  the  language  consists  of  node  names  -  prefixed  by  'M: * 
and  'F:'  to  indicate  whether  the  node  is  a  module  or  a  file, 
respectively,  and  suffixed  by  desired  attributes  -  connected  by  edges 
The  statement  terminates  with  a  *;*. 

1  CONFIGURATION :  REUSABLE; 

2  M : +P1 , +P2 , +P3 , +P4 , +P5 

->F:REQ_R£L(  ORG : MAIL ) 

->Ms R->F : ALLOC(  ORG : POST ) 

-> P ; ALL0C1( ORG s MAIL ), ALL0C2 ( ORG : MAIL ), ALL0C3( ORG s MAIL ) , 
ALLOC 4( ORG: MAIL), ALLOCS  (ORG: MAIL); 

3  P : ALL0C1— >M:P1; 

4  P : ALL0C2— >M:P2; 

5  P: ALL0C3— >M:P3 ; 

6  F : ALL0C4— >M:P4; 

7  F : ALLOCS— >M:P5; 

PIGURE  3.  Specification  of  Configuration  of  Pigure  2 

A  node  in  the  configuration  graph  may  have  a  number  of  optional 
attributes,  especially  a  physical  name  providing  location,  device, 
directory.,  version  and  record  size  (described  in  Part  II).  Default 
values  are  assumed  if  these  attributes  axe  not  provided  (which  is  the 
case  in  Pigure  3).  Also  synonymous  names  may  be  declared.  Module 
node  names  may  be  preceded  by  the  +  sign  to  indicate  that  the  module 
is  not  to  be  initiated  automatically  by  the  comnand  language  programs 
produced  by  the  Configurator,  but  instead  will  be  initiated  manually. 
In  such  a  case  the  manually  initiated  module  must  give  its  identity  in 
the  connecting  file( s ) .  Thus  the  absence  of  such  a  module  would  not 
effect  other  modules. 

Por  example,  a  philosopher  (PI  to  PS)  module  need  not  be 
initiated  automat ically  with  the  resource  allocator  module  (R).  It 
may  be  initiated  when  the  Philosopher  joins  the  dining  arrangement. 


OPERATION  OP  THE  CONFIGURATOR 


3.1  FUNCTIONS  AND  PHASES  OF  THE  CONFIGURATOR 

This  chapter  provides  an  overview  of  the  Configurator.  Part  II 
gives  more  detail  and  systematic  description. 

The  Configurator  has  five  functions:  Checking  the  input 
configuration,  scheduling  execution  of  modules,  evaluating  diameters 
of  strongly  connected  components  (to  be  used  in  the  iterative  solution 
to  the  distributed  simultaneous  equations)  ,  generating  JCL  and  PL/ 1 
programs  and  generating  user  system  documentation. 

The  first  phase  of  the  Configurator  performs  syntactic  checking 
of  individual  statements  and  constructs  a  configuration  graph  where 
the  nodes  are  assigned  all  the  necessary  attributes,  supplied  in  the 
specification  or  determined  by  default  (Section  11.4). 

The  second  phase  analyses  the  graph  and  verifies  that  the  rules 
for  composing  a  complete  and  consistent  specification  of  a 
configuration  ( Section  10.6). 

Deeper  global  checking  is  conducted  as  follows .  Maximally 
strongly  connected  components  ( MSCC )  in  the  configuration  graph  are 
identified  and  the  user  is  warned  that  they  constitute  a  necessary  but 
not  sufficient  condition  for  a  deadlock  (a  deeper  check  is  conducted 
by  the  MODEL  Compiler  for  each  of  the  modules  in  the  MSCC,  described 
later).  Warning  and  error  messages  are  couched  in  the  configuration 
language  and  do  not  refer  to  implementation  level  concepts  (Section 


In  the  third  phase,  the  Configurator  schedules  the  entire  system. 
It  attempts  to  minimize  the  usage  of  mailbox  space.  This  is  based  on 
the  limited  information  available  in  the  configuration,  although 
better  efficiency  could  be  obtained  if  their  intercoeeunication 
pattern  was  known  in  detail.  Processes  of  modules  connected  by  post 
or  mail  files  are  initiated  together  and  operate  in  parallel  if 
possible.  Such  module  nodes  form  a  parallel  component  and  are 
represented  by  a  single  node  in  a  component  graph.  Modules  prefixed 
by  +  sign  are  initiated  manually.  Xf  an  edge  exists  between  the  two 
ISAM  (standing  for  Indexed  Sequential  Access  Mechanism)  files,  it 
implies  that  completion  of  the  producer  modules  must  precede 
initiation  of  the  consumer  modules.  This  graph  consists  of  nodes, 
each  representing  a  module  or  a  group  of  modules  in  a  parallel 
component,  and  edges  indicating  sequential  order  between  nodes.  This 
component  graph  is  checked  for  cycles,  and  error  messages  are  issued 
if  any  cycles  are  found  (Section  11.7). 

The  Configurator  then  calculates  diameter  for  each  strongly 
connected  components  in  a  configuration.  The  diameters  are  needed  in 
the  distributed  termination  algorithm  (Section  11.8). 

In  the  next  phase,  conanand  language  statements  axe  generated  to 
run  the  entire  configuration  of  programs  and  files  in  a  chosen 
environment.  The  program  generation  phase  uses  the  available 
facilities  offered  by  the  operating  systems  and  conmunications 
software  as  well  as  the  available  processors  and  communication  links. 
In  the  case  of  the  implementation  using  VAX/VMS,  both,  sharing  memory 
or  sending  and  receiving  messages,  are  available  for  comnunications 
between  modules.  The  technique  of  code  generation  can  conveniently 
express  either  implementation  strategy.  The  message  communication 
method  was  selected  as  it  is  more  suitable  for  a  geographically 
distributed  network  and  it  retains  better  independence  of  a  program 
from  the  types  of  devices  used;  for  instance,  a  MAIL  file  may  serve 
as  a  sequential  file  (without  user  intervention),  depending  upon 


whether  it  is  used  to  connect  modules  in  a  configuration  or  not 
(Section  11.9). 

Due  to  the  particular  facilities  in  VAX/VMS,  the  programs 
generated  by  the  Configurator  consist  of: 

i)  PL/1  programs  to  establish  the  necessary  mailboxes. 

ii)  command  language  programs  which  initiate  and  synchronize 
sequential  module  or  subsystem  execution. 

The  comnand  language  programs  are  placed  in  respective  files.  These 
files  form  a  tree  structure,  where  each  file  at  a  non-terminal  node 
executes  the  files  in  the  nodes  below  it.  Thus  the  root  file  of  the 
tree  is  the  "main"  cosmand  program  which  contains  oommandn  for 
executing  the  files  which  initiate  subsystems  or  modules,  and  so  on. 
However,  the  command  program  files  for  modules  to  be  initiated 
manually  are  not  present  in  the  tree .  They  are  referred  by  the  user 
for  execution.  In  addition  to  the  cosmand  language  programs  generated 
by  the  Configurator,  there  are  PL/I  program  files  for  each  module 
generated  by  the  MODEL  Compiler. 

A  module  reading  a  record  from  a  mailbox  is  suspended  if  the 
mailbox  is  empty,  until  a  record  has  been  written  by  another  process 
to  the  respective  ma.  j  ox .  A  module  is  suspended  when  writing  a 
record  to  a  full  mailbox,  until  a  record  in  the  mailbox  has  been  read 
by  another  process  and  space  has  become  available.  The  latter 
suspension  is  not  necessary  if  the  space  in  the  mailbox  is  unlimited. 

The  above  coranunicat ion  protocols  synchronize  the  concurrent 
processes.  Sequential  order  of  execution  is  obtained  by  using  the 
synchronization  facility  in  VAX/VMS  comnand  language  [VAX/VMS,  80]. 
It  assures  that  a  predecessor  process  is  completed  before  a  successor 
process  is  initiated. 

Finally  a  number  of  reports  document  the  configuration 
specification,  its  network,  the  modules,  the  files  and  their 


attributes,  the  schedule  and  the  compatibility  requirements  imposed  on 
files  that  connect  modules. 

The  remainder  of  this  chapter  describes  the  main  problems 
encountered  in  the  design  and  implementation  of  the  Configurator  and 
the  methods  used  to  resolve  these  problems. 

3 . 2  CHECKING 

The  checks  performed  by  the  Configurator  cure  divided  into  the 
following  classes: 

i)  Completeness  and  inter-module  connections 

ii)  Consistency  of  (derived)  temporal  relations 

iii)  Compatibility  of  interfacing  file  descriptions 

3.2.1  COMPLETENESS  AND  INTER-MODULE  CONNECTIONS 

The  completeness  Check  detects  the  existence  of  isolated  nodes  in 
a  configuration  (Section  11.5).  The  Configurator  also  checks 
connection  patterns  among  modules  and  connection  restrictions  for  each 
node.  Basically,  the  following  consume/produce  patterns  are  allowed 
for  the  different  file  types: 

MAIL  n:l 
POST  l:n 
SAM  l:n 
ISAM  n:m 

Similar  restrictions  have  been  made  for  MODULE  nodes  and  the 
sumnary  of  the  restrictions  can  be  found  in  Section  10.5. 

3.2.2  CONSISTENCY  OP  TEMPORAL  RELATIONS 


The  underlying  assumption  used  in  the  consistency  checking  is 
that  all  the  modules  in  a  configuration  are  ATOMIC  (section  11.6.1), 


namely  they  acquire  all  their  input  files  on  initiation  and  release 
them  on  termination.  There  are  also  three  temporal  relations  defined 
on  five  basic  module-file  connections  patterns  (section  11.6.1).  Let 
a  pair  of  real  numbers  <Mis,Mie>  be  the  starting  and  ending  times  of 
module  Mi,  the  three  temporal  relations  and  implied  execution  time 
constraints  are: 

i)  sequential  relation,  denoted  as  Mi  «>  Mj , 
implies  Mie  <  Mjs. 

ii)  mail  relation,  denoted  as  Mi  ->  Mj, 
implies  Mjs  <■  Mis  &  Mje  >-  Mie. 

iii)  parallel  relation,  denoted  as  Mi  ||  Mj, 
implies  Mis-Mjs  and  Mie-Mje. 

The  transitivity  of  these  temporal  relations  are  defined  (section 
11.6.1.2).  The  temporal  relations  are  propagated  in  a  configuration 
graph  according  to  those  transitivity  rules. 

An  inconsistency  in  a  configuration  graph  is  obtained  by  deriving 
either  Mi«>Mi  or  Mi->Mj  and  Mi*>Mj  based  on  the  transitivity  rules 
(Section  11.6). 

3.2.3  COMPATIBILITY  OF  INTERFACING  PILE  DESCRIPTIONS 

Because  of  the  independent  development  of  individual  modules,  the 
checking  of  the  compatibility  of  interfacing  file  descriptions  is 
rather  difficult.  However,  messages  are  issued  to  warn  the  user  of 
this  requirement .  Documentation  is  produced  to  show  for  each  file, 
it's  consumer  and  producer  where  compatibility  of  file  structure  is 
required  (Section  10.6). 

3.3  OPTIMIZATION 

The  Configurator  uses  the  component  graph  to  schedule  module. 
Processor  and  memory  usage  is  optimized  by  calling  a  module  as  late  as 
possible  when  its  output  is  needed.  The  concurrency  of  the  overall 
system  is  also  optimized  by  the  use  of  the  component  graph  (Section 


11.6.7). 

3.4  DIAMETER  EVALUATION 

The  diameter  of  each  strongly  connected  component  in  the 
configuration  graph  is  needed  for  the  distributed  termination  of  the 
iterative  multi-node  solutions  (Section  16.2).  The  Configurator 
calculates  the  diameters  of  the  strongly  connected  components  in  a 
configuration  and  passes  the  diameters  to  the  generated  JCL  programs, 
to  be  used  by  individual  modules  at  runtime  ( section  11.8). 

3.5  CODE  GENERATION 


In  this  phase,  the  Configurator  generates  JCL  and  PL/1  programs 
for  the  execution  of  a  user  system.  The  "tree"  structured  execution 
pattern  is  accomplished  by  use  of  the  conmands  in  VAX/VMS.  Detail 
description  of  the  code  generation  part  of  the  Configurator  is  given 


CHAPTER  4 

SPECIFYING  INDIVIDUAL  MODULES  -  RESOURCE  ALLOCATOR 


To  complete  implementation  of  the  configuration  of  Pigure  2,  it 
is  necessary  to  specify  each  module  independently.  In  this 
configuration  there  is  a  philosopher  module.  Which  repeats  five  times, 
one  for  each  of  the  five  philosophers,  and  a  resource  allocator 
module.  The  specifications  of  these  modules  are  discussed  below. 
This  chapter  provides  aui  introduction  to  the  use  of  the  MODEL 
language. 


4.1  THE  PHILOSOPHER  MODULE 


Figure  4  shows  the  specification  of  the  philosopher  module  stated 
in  the  MODEL  language .  The  specification  is  divided  for  convenience 
into  five  parts:  header,  data  description,  data  parameters  and 
internal  and  external  equations.  There  are  also  explanatory  comments 
and  statement  numbers  in  Figure  4.  The  rational  behind  composing  the 
statements  is  discussed  in  the  following. 


The  header  consists  of  the  name  of  the  module  (Pk),  the  source 
file  of  allocations  (ALLOOt)  and  target  file  of  requests  and  releases 
(REQ.HEL).  The  lower  case  k  denotes  the  unique  number  of  each 
philosopher. 


/♦HEADER*/ 

1  MODULE:  Pk( k«l  to  5);  /*  module  name  (repeats  5  times)  */ 

2  SOURCE  PILE:  ALLOCk;  /*  allocation  files  */ 

3  TARGET  PILE:  REO  KEL:  /*  file  of  requests  and  releases  */ 

/♦DATA  DESCRIPTION*/ 

4  1  ALLOCk  IS  PILE( ORGANIZATION  IS  MAIL) 

2  MSGA( * )  IS  RECORD,  /*  individual  allocation  message  */ 

3  PROC_lD  IS  PIELD( PIC ' 9 ' ),  /*  process  identifier  */ 

3  CLOCKA  IS  PIELD(BIN  PIXED ) ;  /*  time  of  allocation  */ 

5  1  REQ_REL  IS  FILE( ORGANIZATION  IS  MAIL) 

2  MSGR( * )  IS  RECORD,  /♦  request/ release  message  */ 

3  PROC_ID  IS  PIELD(PIC'9' ),  /*  req/rel  process  id  */ 

3  RQ_OR_RL  IS  PIELD(  BIT(  1 ) ) ,  /*  request-0 , release-1  */ 

3  RES( 5 )  IS  PIELD(PIC*9'  ),  /*  quantities  of  resources*/ 

3  CLOCXR  IS  PIELD( BIN  PIXED);  /*  req/rel  time  */ 

/♦DATA  PARAMETERS*/ 

6  (I,J)  ARE  SUBSCRIPTS;  /*  I  for  MSGR,  J  for  RES  */ 

7  IX  IS  FIELD( FIXED  BINARY)  /*  indirect ( sublinear )subscript*/ 

8  IX( I )-IF  1-1  THEN  1 

ELSE  IP  RQ_OR_RL(  I— 1 )  THEN  IX(I-1)+1 

ELSE  IX( I— 1 ) ;  /*  index  of  MSGA  */ 

9  END . MSGR(  I  )-RQ_OR_RL( I )  &  RANDOM) .99; 

/*  definition  of  the  range  of  MSGR  */ 

/♦EQUATIONS  FOR  VARIABLES  IN  PILE  REQ_REL*/ 

10  PROC_ID(I)-<k>; 

11  RQ_0RJRL< I )— IF  1-1  THEN  *0'B  ELSE  ~RQ_OR_RL( 1-1 ) ; 

12  RES(I,J)-(J-H0D<k,5))|(J-M0D(k+l,5)); 

/*  right  and  left  fork  request  */ 

13  CL0CXR(  I )-IF  1-1  THEN  TIME 

ELSE  IP  RQ_OR_RL<  I )  THEN  CL0CXA(  IX(  I—l )  )— 1000*L0G(  RANDOM) 
ELSE  CL0CXR(  I—l )— 10QOO*LOG(  RANDOM  ) 


/♦EQUATION  DEPINED  EXTERNALLY  (IN  OTHER  MODUIES)*/ 
14  MSGA( IX( I ) )-DEPENDS_ON( MSGR( I  )  ); 


FIGURE  4.  Specification  of  Philosopher  Module 


The  data  description  part  in  Figure  4  declares  the  structure  of 
the  two  files.  A  data  structure  is  described  hierarchically  as  a 
tree.  The  apex  node  is  called  PILE,  an  intermediate  node  is  either  a 
GROUP  or  a  RECORD.  A  RECORD  is  the  smallest  structure  exchanged 
between  an  external  environment  or  device  and  the  module.  A  terminal 
node  is  denoted  as  a  field.  Each  of  the  nodes  is  named,  and  may 
repeat  and  form  a  vector.  The  number  of  repetitions,  or  size  of  the 
vector  is  in  parenthesis  following  the  name.  "*”  indicates  an  unknown 
(variable)  number  of  repetitions.  The  primitive  data  types  are 
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3  uni  lair  to  PVI  -  picture,  decimal  ( f  i:  ioat),  binary,  bit  and 
character.  Thus  the  ALLOCk  file  (stateme-  e  ontains  a  vector  of 
allocation  messages  (records)  MSGA.  Tn*.  .j^q  REL  file  (statement  5) 
contains  a  vector  of  requests/ re leases  messages  (records)  MSGR.  These 
two  entire  vectors  are  viewed  by  the  user  as  they  were  available  a 
priori  and  his  main  task  is  to  compose  equations  which  relate  them. 

A  philosopher  requesting/releasing  resources/ forks  identifies 
himself  in  the  PROC_ID  field  of  MSGR.  The  philosopher  to  whom 
resources  are  allocated  ( i . e .  by  the  resource  allocator  module )  is 
identified  in  the  PROC_ID  field  of  MSGA.  TTie  records  in  the  ALLOCk 
file  come  from  a  post  organized  file.  MSGR  may  be  for  a  request  or  a 
release  of  resources,  and  RQ_OR_RL  denotes  which  case  it  is.  Each 
MSGR  includes  a  vector  of  resources  RES,  which  contains  the  quantity 
of  each  resource  that  is  requested  or  released.  There  are  5  resources 
in  the  problem  of  the  5  dining  philosophers  -  each  consisting  of  a 
single  fork  in  a  respective  position.  Finally,  CLOCXA  and  CLOCKR  are 
used  to  simulate  the  clock  (in  seconds)  of  an  allocation  and 
request/ release,  respectively. 

Repeating  data  structures  form  arrays.  The  individual  elements 
of  these  arrays  are  referred  to  by  use  of  subscripts.  The  sizes  of 
dimensions  of  arrays  may  be  variable  and  need  to  be  defined.  They 
constitute  the  data  parameters  of  the  specification  in  Figure  4. 
Statement  6  declares  two  free  variables  I  and  J  that  are  used  as 
subscripts.  They  assume  all  the  integer  values  from  1  to  the  size  of 
the  dimension  of  the  variable  which  they  index.  Note  that  they  differ 
from  ordinary  variables  which  can  assume  only  a  single  value.  I  is 
used  to  subscript  the  request/release  messages,  (MSGR  and  its 
constituents),  and  J  to  subscript  the  resources,  RES.  Note  that  RES, 
the  requested  or  released  resources,  changes  for  each  message  and 
therefore  is  two-dimensional,  with  subscripts  I,J.  I  indexes  the 
"historical"  values  of  RES.  There  is  a  correspondence  between 
individual  allocations  and  requests/releases .  For  each  requesting 
MSGR,  (where  RQ_0R_RL-0 ) ,  there  is  a  corresponding  allocation  MSGA. 


Mo  MSGA  is  necessary  for  a  release  MSGR,  (with  RQ_0R_RL*1 ) . 


A  widely  used  method  in  MODEL  for  relating  elements  in  two  arrays 
is  to  define  separately  the  indices  of  the  related  elements.  This  is 
the  case  in  defining  am  indirect  index  vector  IX  (an  internal 
variable)  which  gives  the  indices  of  MSGA  for  each  index  I  of  MSGR. 
IX  is  declared  in  statement  7  and  defined  in  statement  8.  IX  is  a 
vector  of  the  same  shape  as  MSGR.  Thus  it  has  a  value  for  each  value 
of  I.  Por  I*l  it  has  a  value  1.  Then,  IX  is  increased  by  one  if  the 
preceeding  MSGR  is  a  release.  We  call  IX  3ublinear  to  I.  The 
sublinear  relation  between  IX  and  I  satisfies  two  conditions: 
IX( 1 )— 0 1 1  and  IX( I )-IX( 1-1 )*0 1 1 .  The  program  generator  recognizes 
sublinearity  and  uses  it  to  generate  a  more  efficient  object  program. 
IX  is  referred  later  in  statement  13. 


a)  Illustration  of  External  Dependency  Edge 


Subscripts 

Record 

Record 

I 

IX(I) 

MSGR 

Dependency 

MSGA 

1 

1 

request 

1  external/ R1 

^  allocation  l 

z 

1 

release 

1  internal(P )~ 

3 

2 

request 

2  external/ HI 

^  allocation  2 

4 

2 

release 

2  intemal(  P ) 

b)  Indices  of  Records  in  the  External  Dependency  Statements 


FIGURE  5.  External  Dependency  As  Viewed  Prom  The  Philosopher  Module 
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Figure  6(b)  illustrates  the  relations  o£  these  subscripts  and 
records.  (The  Dependency  column  is  described  later). 

A  condition  o£  the  last  element  in  a  dimension  is  denoted  in 
MODEL  by  a  variable  named  by  prefixing  END  to  the  name  of  a  variable 
with  the  rightmost  (lowest  order)  dimension.  This  variable  has  the 
same  shape  as  the  one  named  in  it's  suffix.  All  it's  elements  have  a 
value  0,  except  £or  the  last  element  in  the  rightmost  dimension  which 
has  value  1.  Statement  9  defines  END. MSGR,  which  has  the  same  shape 
as  MSGR  and  effectively  gives  the  size  of  MSGR.  it  expresses  an 
assumption  that  a  philosopher,  after  having  dined  repeatedly,  on  the 
average  100  times,  exponentially  distributed,  has  had  enough  and 
decides  to  quit  and  dine  elsewhere.  Thus  every  element  in  END . MSGR( I ) 
has  a  value  of  o,  except  the  last  element  which  has  a  value  of  1. 

Statements  10  through  13  define  the  four  FIELD  variables  in  the 
REQ_REL  file.  PROC_ID  is  the  philosopher  identification.  The  value 
of  RQ_0R_KL  is  0  for  a  request  and  1  for  a  release.  The  requests 
forks  in  RES  are  always  to  the  left  and  right  of  the  philosopher,  as 
expressed  in  statement  12.  CLOCXR  simulates  the  time  stamp  of  a 
request  or  of  a  release  of  resources.  Statement  13  shows  that  for 
I«1 ,  CLOCXR  is  the  time  of  the  first  dining  request  (defined  by  the 
function  TIME),  otherwise  it  depends  on  the  time  of  the  previous 
allocation  ( CL0CXA(  IX(  1-1 ) ) )  and  the  dining  and  thinking  times  which 
are  assumed  to  be  exponentially  distributed  with  looo  and  loooo 
seconds  means  respectively.  Mote  that  this  assumes  that  a  philosopher 
may  join  and  quit  the  diners  at  any  time  of  his  choice  and  the  number 
of  philosophers  may  be  variable.  However,  each  philosopher  must  have 
a  seat  assigned  at  the  table  in  advance  of  the  first  eating. 

To  specify  the  philosopher  module  completely  it  is  further 
necessary  to  specify  external  dependencies  due  to  functions  provided 
by  other  modules.  The  functions  provided  by  the  outside  environment, 
however  complex  they  may  be,  interest  the  module  specification  only  to 
the  extent  of  knowing  that  they  exist.  While  the  outside  relation  may 
change,  as  long  as  the  dependency  continues  to  hold  it  is  not 
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necessary  to  respecify  the  module.  In  our  example  it  is  necessary  to 
specify  in  a  philosopher  module  the  external  function  of  an  allocation 
in  response  to  a  respective  request  ( this  dependency  is  imposed  by  the 
resource  allocator  module).  It  is  not  necessary  to  show  this 
relationship  in  detail  as  expressed  in  the  R  module.  A  user  can 
express  it  in  a  reduced  form  as  shown  in  statement  14  of  Figure  4. 
The  pseudo  function  DEPENDS_ON  is  used  to  express  the  fact  that  the 
source  record  variable( s )  on  the  left  hand  side  depend  externally  on 
the  target  record  parameters  of  the  function.  Note  that  the  internal 
dependency  of  a  release  on  an  allocation  is  expressed  implicitly  in 
equation  13.  These  two  dependencies  are  illustrated  by  the  labeled 
arrows  in  the  table  at  the  bottom  of  Figure  5. 

4.2  THE  RESOURCE  ALLOCATOR  MODULE  R. 

Figure  6  shows  the  specification  of  the  resource  allocator  module 
R.  The  R  module  is  larger  and  more  complex  than  the  philosopher 
module.  It  further  illustrates  the  equational  style. 

Statements  1-3  in  Figure  6(a)  give  the  name  of  the  module,  R,  the 
source  file  REO  REL.  and  target  file  ALLOC.  Another  target  file 
SIMULATION  is  a  report  of  the  results  of  the  simulation  of  the  Dining 
Philosophers  problem.  The  specification  of  SIMULATION  is  given  in 
statements  in  Figure  6(c).  KEQ_REL  and  ALLOC  are  declared  in 
statements  4  and  5  of  Figure  6(a).  REL_REQ  consists  of  the  combined 
requests/releases  received  in  the  mail  from  all  other  modules  in  the 
sequence  of  their  arrival.  ALLOC  consists  of  all  the  allocations  of 
resources  distributed  through  the  post  office  like  facility  to  all  the 
modules  in  the  order  that  they  are  issued.  Note  that  the  records  in 
ALLOC  form  a  two  dimensional  ragged  edge  matrix,  with  each  row 
corresponding  to  all  the  allocations  that  can  be  made  in  response  to  a 
respective  request  or  release  message.  This  differs  from  the  vector 
organization  of  ALL0C3c.  However  this  does  not  violate  the  rules  of 
compatibility  of  comnunicating  files. 
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/♦HEADER*/ 

1  MODULE :R; 

2  SOURCE : REO  REL ;  /*  merged  requests/re leases  from  all  processes  */ 

3  TARGET: ALLOC,  /*  merged  allocations  to  all  processes  */ 

SIMULATION ; /*  report  of  results  of  simulation  */ 

/*DATA  DESCRIPTION*/ 

4  1  REQ_REL  IS  PILE,  (ORG  IS  MAIL), 

2  MSGR( * )  IS  RECORD,  /*  messages  for  req/rel  of  resources  */ 

3  PROC_ID  IS  FIELD  (PIC' 9*  ),  /*  id  of  process  */ 

3  RQ_OR_RL  IS  FIELD  (BIT(l)),  /*  requests , release=l  */ 

3  RES( 5 )  IS  FIELD  (PIC' 9' ),  /*  vector  of  resources  */ 

3  CLOCXR  IS  FIELD  (PIC'(9)9');  /*  time  of  message  */ 

5  1  ALLOC  IS  FILE,  (ORG  IS  POST,  KEY  IS  PROC_ID), 

2  MSGAS( * )  IS  GROUP,  /*  group  of  alloc  messages  */ 

3  MSGA(  * )  IS  RECORD,  /*  individual  message  */ 

4  PROC_ID  IS  FIELD  (PIC 9'),  /*  allocated  process  */ 

4  CLOCKA  IS  FIELD  ( PIC' ( 9  )9 ’  );/*  time  of  allocation  */ 

6  1  QUEUE  IS  FILE,  /*  process  queues  */ 

2  STAT_Q( * )  IS  GROUP,  /*  queue  for  each  req/rel  */ 

3  PROC( * )  IS  GROUP,  /*  process  in  queue  */ 

4  PROC_ID  IS  FIELD  (PIC* 9* ),  /*  id  of  process  */ 

4  IN_IX  IS  FIELD  (PIC* 9* ),/*index  of  process  in  queue  */ 

4  OOT_IX  IS  FIELD  (PIC 9*  ),  /*  index  of  process  in  alloc  */ 

4  RES( 5 )  IS  GROUP,  /*  resource  vector  */ 

5  CLAIM  IS  FIEU)  (PIC 9*  ),  /*  maximum  resources  claimed  */ 

5  SUM_CLAIM  IS  FIELD  (PIC'9*), 

/*  sums  of  claims  for  resources  in  q  */ 

5  SAT  IS  FIELD  (BIT(l));  /*  availability  of  resources  */ 

7  1  RES_LIMIT  IS  GROUP, 

2  NUH_RES<5)  IS  FIEID  (PICS'  )}  /*  «  of  resources  available  */ 


/*DATA  PARAMETERS*/ 

8  (I,J,K,L)  ARE  SUBSCRIPTS; 

/*  I  subscript  of  request/release  messages  */ 


/*  J  subscript  of  resources  */ 

/*  K  subscript  of  processes  in  queue  */ 

/*  L  subscript  of  group  of  allocations  */ 

9  SIZE .  PROC(  I  )**IF  I=-l  THEN  1 

ELSE  IF  RQ_OR_RL(I)  THEN  SIZE . PROC( 1-1 )-l 

ELSE  SIZE . PROC( I— 1 )+l ; 

/*  size  of  process  queue  */ 

10  SIZE.MSGA( I  )=  IF  SIZE . PR0C( I  ) >0  THEN  0OT_IX( I , SIZE . PROC( I ) ) 

ELSE  0; 

/*  size  of  group  of  allocations  */ 

11  NUM_RES( J )-l ;  /*  one  fork  in  each  position  */ 


FIGURE  6(a)  Resource  Allocator  Module  Specification:  Header, 

Data  Description  and  Definition  of  Data  Parameters 

The  file  compatibility  rules  axe  briefly  summarized  below, 
i)  The  data  structures  that  constitute  the  unit  of  transfer  of 
information  between  different  media  in  a  computer  system  axe 
denoted  as  records .  A  match  must  be  possible  between  the 
variables  in  the  corresponding  records  in  producing  and  consuming 


nodule  specifications .  The  lengths  ( in  bytes )  of  matching 
records,  specified  separately  in  the  consumer  and  producer 
modules,  must  be  the  same. 

ii )  Matched  variables  in  the  respective  records  may  be  named 
differently  in  the  producer  and  consumer  module  specifications, 
but  they  must  have  the  same  attrloutes,  i.e.  data  type,  scale 
and  length. 

iii)  Matched  records  may  form  arrays  in  respective  specifications.  It 
is  not  necessary  that  the  number  of  dimensions  of  the  arrays  in 
the  specifications  of  the  file  in  consumer  and  producer  modules 
be  the  same,  but  the  total  number  of  records  must  be  the  same. 

There  is  also  an  internal  QUEUE  file  consisting  of  the  history  of 
the  status  of  the  queue  of  processes .  It  repeats  for  each 
request/release.  Processes  are  added  and  retained  in  the  queue  in  the 
order  of  the  respective  requests,  and  omitted  as  a  result  of 
respective  releases.  The  QUEUE  file  is  described  in  statement  6. 
STM?  Q  is  the  status  of  the  queue  for  each  request/ release  message. 
The  individual  entry  in  the  queue  is  PRDC.  it  contains  the 
identification  of  the  process  PROC_ID .  Two  indirect  index  variables, 
IN_IX  and  out_IX  are  described  further  below.  A  vector  RES  contains 
information  on  requested  resources.  RES  is  a  matrix  with  rows 
corresponding  to  processes  and  columns  corresponding  to  resources. 
The  components  of  RES,  i.e.  CLAIM,  SUM_CIAEM  and  SAT,  are  therefore 
also  matrices.  (Actually  3  dimensional,  repeated  for  each 
request/release).  CLAIM  is  the  number  of  resources  claimed  by  the 
process.  SUM.CLAIM  is  the  cumulative  number  of  resources  needed  to 
satisfy  all  the  claims  by  this  process  and  it's  predecessors  in  the 
queue.  SAT  is  a  binary  variable  indicating  for  each  process  whether 
the  claims  for  a  resource  and  it's  predecessors  resources,  in  the 
order  of  resources  in  RES,  can  be  satisfied  from  available  resources. 

It  is  typical  in  MODEL  to  specify  permutation  or  selection  of 
elements  of  a  vector  by  defining  the  indices  of  the  respective 
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elements.  IN_IX  is  the  index  o£  a  process  in  the  preceding  queue, 
i.e.  in  STAT_Q( 1-1 ) .  A  number  of  processes  may  be  allocated 
resources  as  a  result  of  a  release  message.  OUT_lX  is  the  index  of 
the  process  in  the  respective  group  of  allocation  messages.  Both, 
XN_IX  and  OUT_IX  increase  monotonically  with  the  order  of  the 
processes  in  the  queue.  These  variables  are  discussed  further. 

A  number  of  parameters  are  used  with,  or  are  attributes  of,  the 
data.  The  subscripts  I,J,K  and  L  are  declared  in  statement  8.  The 
subscript  I  indexes  request/release  messages.  J  indexes  resources 
( forks ) .  K  indexes  positions  of  processes  in  the  queue  and  L  indexes 
allocation  messages .  There  sure  three  dimensions  that  require 
definition  of  their  sizes.  The  range  of  I  is  assumed  as  infinity 
reflecting  the  notion  that  R  will  operate  forever.  There  are  a  number 
of  ways  to  define  a  size  of  a  dimension  in  MODEL.  The  use  of  the  END 
prefixed  variable  was  already  presented  in  Figure  4.  Another  way  to 
define  a  size  is  through  prefixing  the  keyword  SIZE  to  the  name  of  a 
respective  data  structure.  SIZE  prefixed  variables  define  the  number 
of  elements  in  the  respective  dimension.  The  size  of  the  vector  PROC, 
i.e.  the  number  of  processes  in  a  queue,  is  defined  in  statement  9. 
As  shown  in  statement  9,  the  size  of  the  queue  increases  by  one  for 
each  request  and  decreases  by  one  for  each  release.  The  size  of  the 
vector  MSGA,  i.e.  the  number  of  allocations  in  a  group  is  defined  in 
statement  10.  The  size  of  the  group  of  allocation  messages,  MSGA,  is 
the  same  as  the  value  of  0UT_IX  for  the  last  process  in  the  queue. 
This  is  discussed  further  below.  Figure  6(a)  ends  with  definition  of 
RES  the  number  of  resources  of  each  type  -  namely  there  is  1  fork  for 
each  of  the  five  fork  positions. 

Figure  6(b)  shows  the  equations  for  variables  in  the  two  files 
QUEUE  and  ALLOC  and  the  external  dependencies.  There  are  several  same 
named  variables  in  different  files  and  the  name  of  the  respective  file 
is  used  as  a  prefix  to  remove  the  ambiguity.  QUEUE. PR0C_ID,  the 
identity  of  a  process  in  the  queue,  is  defined  in  statement  1Z  for  two 


cases  -  for  adding  a  process  corresponding  to  a  request,  or  for 


retaining  a  process  in  the  queue.  IN_IX  gives  the  index  of  the 
process  in  the  preceeding  (I-l)th  status  of  the  queue. 


/*  EQUATIONS  FOR  VARIABLES  IN  FILE  QUEUE  */ 

12  QUEUE .  PROC_ID(  I ,  K  )-  IF  ‘*RQ_OR_RL(  I  )  &  ( K-SIZE . PROC(  I ) ) 

THEN  HEQ_REL.PROC_ID( I ) 

ELSE  QUEUE . PROC_ID( 1-1 , IN_IX(  I , K ) ) ; 

13  IN_IX(I,K)«  IF  *RQ_OR_RL(I)  THEN  K 

ELSE  IF  KEQ_KEL.PROC_ID( I )~=QUEUE.PROC_ID( I— 1,K) 
THEN  IF  K-l  THEN  1  ELSE  IN_IX( I,  K-l )+l 
ELSE  IF  K-l  THEN  2  ELSE  IN_IX(  I,K-l)4-2; 

14  OUT_IX( I,K)-IF  RQ_OR_RL( I )  THEN 

IF  SAT(I,K,5)S  -SAT(I-1,IN_IX(I,K),5) 

THEN  IF  K-l  THEN  1  ELSE  OUT_IX( I , K-l ) +1 
ELSE  IF  K-l  THEN  0  ELSE  OUT_IX( I , K-l ) 

ELSE  IF  K^SIZE . PROC( I )&SAT( I , K , 5 )  THEN  1  ELSE  0; 

15  CLAIM(I,K,  J)-  IF  "*RQ_0R_RL(  I  )  &  ( K— SIZE . PROC(  I  )  ) 

THEN  REQ_REL.RES(I,J) 

ELSE  CLAIM(  I— 1,  IN_IX(  I,K ) ,  J  ); 

16  SUH_CLAIM(I,K,J)-  IF  K-l  THEN  QUEUE. CLAIH(  I,K,  J) 

ELSE  QUEUE.CLAIM(I,K, J)+SUM_CLAIM(I,K-1,  J); 

17  SAT( I,K, J)— IF  J-l 

THEN( SUM_CLAIM( I , K , J ) <«NUM_RES( J ) | QUEUE . CLAIM( I , K , J )-0 ) 

ELSE  SAT( I ,K, J— 1 )  S 

(  SUH_CLAIM(  I , K ,  J  ) <-NUH_RES(  J  )  |  QUEUE .  CLADK  I , K,  J  )-0  ) ; 

/•  EQUATIONS  FOR  VARIABLES  IN  FILE  ALLOC  */ 

18  ALLOC . PROC_ID< I , OUT_IX( I,K ) )— 

IF  (K— 1  &  OUT_IX<I,K)-l>l(K>lfiOOT_IX(I,K)>OUT_IX(I,K~l)) 
THEN  QUEUE . PROC_ID( I , K  ) ; 

19  CL0CXA(  I ,  L  )-CL0CXR(  I  )  ; 

/*  EQUATIONS  FOR  EXTERNAL  DEPENDENCIES  */ 

20  KSGR(  I )— DEP_ON(  MSGA(  I— 1 ,  L  )  )  ; 


FIGURE  6(b)  Resource  Allocator  Module  Specification: 

Equations  For  Variables  in  Files  QUEUE  and  ALLOC 
and  the  external  dependencies 


When  the  Ith  MSGR  corresponds  to  a  request  then  the  requesting  process 
is  added  in  the  last  position.  In  the  case  of  a  release,  the  resource 
releasing  process  is  deleted  from  the  queue.  0UT_IX,  defined  in  line 
14,  is  monotonically  increasing  along  the  queue.  Processes  in  the 
queue  that  are  not  being  allocated  resources  have  an  0UT_IX  'value 
equal  to  the  preceding  process,  while  0UT_IX  is  increased  for 
processes  which  are  allocated  resources.  As  it  is  easy  to  verify,  in 
the  case  of  the  dining  philosophers,  there  may  be  0,  1  or  2 
allocations  for  each  I. 


As  defined  in  statement  15,  CLAIM,  the  maximum  number  of 
resources  of  each  type  requested  by  a  process,  is  contained  in  the 
respective  request  and  also  retained  in  the  queue.  SUM_CLAIM,  defined 
in  statement  16,  is  the  cumulative  number  of  resources  of  each  type 
needed  to  satisfy  the  claims  of  a  process  and  all  its  predecessors  in 
the  queue.  If  SUM_CLAIM(  I,K,  J)  exceeds  NUM_KES(J),  the  total  number 
of  copies  of  a  resource,  then  the  respective  CLAIM(I,K,J)  can  not  be 
satisfied .  This  condition  is  used  to  define  SAT  in  statement  17 . 

Statements  18  and  19  define  the  identity  of  the  process  that  is 
allocated  resources  ( ALLOC . PROC_ID ) ,  and  the  simulated  time  of  the 
allocation  (CLOCKA).  Statement  19  neglects  the  computation  time  for 
computing  the  allocation.  As  noted,  the  latter  is  useful  in  a 
simulation  report  of  the  Dining  Philosophers  problem. 

Finally  the  equation  for  the  external  dependency,  as  seen  by  the 
R  module  is  shown  in  statement  20.  This  equation  expresses  the 
outside  dependency  of  a  release  on  a  previous  allocation.  It  is 
illustrated  in  Figure  7. 

One  of  the  advantages  of  this  style  of  programming  is  the  ease  of 
making  complex  changes.  For  instance,  if  we  wanted  to  give  priority 
in  allocations  to  some  modules,  we  would  have  to  add  priority 
variables  to  the  declaration  of  requests  ( statement  4 )  and  only  modify 
the  equation  for  SAT  ( statement  17 )  to  include  the  dependence  on  the 
priority  variables . 

As  noted,  the  dependency  need  not  express  fully  the 
allocation-release  relations.  In  the  R  module,  the  dependency  is 
visualized  in  terms  of  the  combined  request/ re leases  file,  received 
from  all  the  philosopher's  modules.  Namely,  the  index  of  allocation 
to  a  Philosopher  must  be  less,  at  least  by  1  (i.e.,I-l)  than  the  index 
of  a  release. 

To  obtain  a  printed  output  file  of  the  simulation  results  of  the 
Dining  Philosophers  problem,  it  is  necessary  to  define  a  report, 
called  SIMULATION.  As  shown  in  Figure  6(c)  statement  21,  this  file 


contains  the  identification  of  the  philosophers  and  the  respective 
times  of  requests  and  allocations  of  forks.  Statements  22-26  define 
the  values  in  this  file  as  equal  to  respective  PROC_lD,  CIOCKR  and 
CLOCKA  variables.  For  each  request  there  may  be  0,1  or  2  allocations. 


21  1  SIMULATION  IS  FIIE, 

2  HD1  IS  RECORD, 

3  HDP1  IS  PIELD(CHAR  125), 

2  HD2  IS  RECORD, 

3  HDF2  IS  FIEID(CHAR  125), 

2  HD3  IS  RECORD, 

3  HDF3  IS  FIELD(  CHAR  125), 

2  EVENT( * )  IS  RECORD, 

3  REQUEST  IS  GRP, 

4  PR0C_IDM  IS  FIELD( CHAR  4), 

4  FILLER1  IS  FIELD( CHAR  1), 

4  RQ_OR_RIM  IS  FIELD( CHAR  3), 

4  FILLER2  IS  PIELD( CHAR  1), 

4  RESM(  5  )  IS  FIEU)(PIC  '9'). 

4  FILLERS  IS  FIELD( CHAR  1), 

4  CLOCKRM  IS  FIELD(PIC  'B(12)9'), 
4  FILLER4  IS  PIELD<  CHAR  2), 

3  ALLOCATION ( * )  IS  GRP, 

4  FILLER5  IS  FIELD( CHAR  1), 

4  PR0C_IDA  IS  FIEID(CHAR  4), 

4  FILLERS  IS  FIELD( CHAR  1), 

4  CLOCKA  IS  FIELD( PIC  ,B(12)9,>; 


22 

23 

24 

25 

26 

27 

28 

29 

30 


SIMULATION .HDF1- 
SIMULATION . HDF2- 
SIMDLATION . HDF3- 


'  REQUEST  XL*)) 

•LOCATION* ; 

•p_id  R/I*  resrc  time  p_id  time*!) 

'  p_id  time  p_id  time  • ; 


( FILLER1 , FILLER2 , FILLERS , FILLER4 , FILLERS , FILLER6 )  •; 

SIMULATION . PR0C_IDM  -REQREL. PRDC_IDM; 

SIMULATION.  RESM  -REQREL .  RESM; 

SIMULATION.  CLOCKRM  -REQREL .  CLOCKRM  ; 

SIMULATION . PROC_IDA  -SUBSTR(  ALLOC . PROC_ID ,6,1); 
SIMULATION. CLOCKA  -ALLOC .CLOCKA; 


FIGURE  6(c).  Simulation  Report  Specification  of  the 
Resource  Allocation  Module 
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External  Environment 
(Philosopher's  modules) 


a)  Illustration  of  Dependency  Edge 
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b)  Dependency  Relations 

FIGURE  7 .  Illustration  of  External  Dependencies  As  Viewed 
Prom  the  R  Module 


CHAPTER  5 

THE  OPERATION  OR  THE  MODEL  COMPILER 

The  implementation  of  the  configuration  of  Pigure  2  requires 
specification  of  each  module  independently,  and  its  submission  as 
input  to  the  MODEL  Compiler.  A  brief  description  is  given  here  of  the 
key  problems  and  methods  in  the  MODEL  Compiler .  Hie  following  two 
chapters  describe  specification  of  modules  and  introduce  the  MODEL 
language. 

The  previously  developed  MODEL  Compiler  [Prywes,  83]  was  extended 
for  concurrent  prograneoing .  It  performs  the  following  major  tasks  in 
translation  of  a  specification  into  the  procedural  program.  After 
syntax  analysis,  the  compiler  constructs  a  dataflow-like  graph  to 
represent  the  specification  in  a  convenient  form.  Based  on  the  graph, 
implicit  information  is  derived  and  entered,  checks  are  conducted  and 
an  optimally  efficient  schedule  of  program  execution  is  derived.  The 
optimized  schedule  is  finally  transformed  into  a  procedural  program  in 
PL/l .  The  generated  program  includes  also  analysis  of  various 
conditions  of  program  failure,  such  as  data  type  errors,  absence  of 
expected  records ,  etc . ,  and  recovery  from  such  failures . 


5.1  REPRESENTATION  OP  THE  SPECIFICATION  AS  AN  ARRAY  GRAPH 

The  specification  is  represented  by  an  array  graph,  where  a  node 
represents  the  accessing,  storing  or  evaluation  of  an  entire  array  and 
the  edges  represent  dependencies  among  variables.  Hie  underlying 


graph  of  elements  of  the  array  may  be  derived  from  the  array  graph 
based  on  the  attributes  of  dimensionality,  range,  and  forms  of 
subscript  expressions ,  which  are  given  for  each  node  and  edge  in  an 
array  graph.  A  data  node  has  as  attributes  the  ranges  for  its 
dimensions  and  its  data  type.  An  equation  node  has  as  attributes 
subscripts  and  ranges  corresponding  to  the  union  of  subscripts  of  the 
variables  appearing  in  the  equation.  A  node  A  corresponding  to  a  m 
dimensional  data  or  equation  array  represents  the  elements  from 
A( 1, 1, . . . , 1 )  to  A( N1 , N2 , . . . , Nm )  where  Nl...Nm  are  the  ranges  of 
dimensions  1  to  m  respectively.  Similarly  a  directed  edge  represents 
all  the  instances  of  dependencies  among  the  array  elements  of  the 
nodes  at  the  ends  of  the  edge  and  has  as  attributes  subscript 
expressions  for  each  dimension.  The  edges  have  the  subscript 
expression  for  each  dimension  as  attributes.  The  dependencies  imply 
precedence  relationships  in  the  execution  of  the  respective  implied 
actions.  There  are  several  types  of  them.  For  example,  a 
hierarchical  precedence  refers  to  the  need  to  access  a  source 
structure  before  its  components  can  be  accessed,  or  vice-versa,  the 
need  to  evaluate  the  components  before  a  structure  is  stored  away. 
Data  dependency  precedence  refers  to  the  need  to  evaluate  the 
independent  variables  of  an  equation  before  the  dependent  variable  can 
be  evaluated.  Similarly,  data  parameters  of  a  structure  (such  as  SIZE 
of  a  dimension)  must  be  evaluated  before  evaluating  the  respective 
structure . 


5.2  CHECKING  COMPLETENESS  AND  CONSISTENCY  OF  A  SPECIFICATION 

It  is  inevitable  that  the  user  will  make  mistakes  in  specifying  a 
computation,  and  it  is  necessary  to  have  a  dialog  that  helps  the  user 
to  formulate  a  specification  and  make  corrections.  The  automatic 
program  generation  can  not  be  completed  when  a  specification  is 
inconsistent  or  incomplete.  Therefore  checking  of  structural 
consistency  i3  conducted  on  a  global  basis  with  special  focus  on 
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iterative  and  recursive  relations  which  usually  encompass  many 
entities  in  a  specification.  The  specification-wide  checks  are 
categorized  into  checks  of  completeness,  non-ambiguity  and 
consistency.  Incompleteness  and  ambiguity  are  detected  in 
constructing  the  array  graph  while  special  procedures  check 
consistency.  The  consistency  checking  of  the  entire  specification  may 
be  essentially  regarded  as  "propagation"  of  data  type,  dimensionality 
and  ranges ,  from  node  to  node.  The  problems  discovered  are  described 
to  the  user  in  terms  of  the  very  high  level  language  specification, 
without  referring  to  programing  details.  The  compiler  is  tolerant  of 
many  kinds  of  omissions.  Data  description  statements  are  generated 
for  variables  referred  in  the  equations  but  not  described  by  the  user. 
Equations  are  generated  to  relate  same  named  input  and  output 
variables.  Finally,  circular  logic  is  recognized  by  irresolvable 
cycles  in  the  array  graph  (discussed  further  below). 


5.3  OPTIMIZATION  OF  PRODUCED  PROGRAMS 

In  composing  a  specification  of  a  computational  task,  the  user 
chooses  a  natural  and  convenient  representation.  It  is  up  to  the 
MODEL  Compiler  to  map  the  user's  representation  into  an  efficient 
procedural  computer  program.  An  overall  flow  of  program  events  is 
produced  first  in  a  skeletal,  object  language  independent  form  called 
a  schedule .  The  final  program  generation  phase  translates  individual 
entries  in  the  schedule  into  statements  in  the  object  language  and 
further  optimizes  the  produced  program. 

The  general  approach  to  scheduling  consists  of  creating  first  a 
component  graph  which  consists  of  all  the  maximally  strongly  connected 
components  (MSCC)  in  the  array  graph  and  the  edges  connecting  the 
MSCCs.  The  component  graph  is  therefore  an  acyclic  directed  graph, 
this  graph  can  be  topologically  sorted.  There  is  a  large  number  of 
possible  linear  arrangements  of  the  schedule  which  have  varying 
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efficiencies.  The  objective  is  to  find  a  near  optimal  schedule. 

This  is  done  as  follows.  The  subscripts  for  each  node  in  the 
array  graph  are  determined.  Iterations  for  these  subscripts  must 
bracket  the  respective  nodes  to  define  all  the  values  of  the  elements 
variables  in  the  array  nodes.  Each  node  must  be  enclosed  within 
loops,  which  axe  nested  if  the  respective  equations  or  data  arrays  axe 
of  multiple  dimensions.  Next,  attempts  are  made  to  enlarge  the  scope 
of  iterations.  Nodes  with  the  same  range  can  be  merged  into  larger 
components.  Merging  scope  of  iterations  may  enable  sharing  memory 
locations  by  elements  of  the  same  or  related  array  variables.  If  it 
is  possible  to  retain  in  memory  only  a  window  of  the  entire  dimension 
of  a  variable,  then  the  respective  dimension  is  called  virtual . 
otherwise  it  is  called  physical .  When  there  is  a  number  of  ways  that 
components  can  be  merged  ( for  different  dimensions )  then  the  memory 
requirements  of  different  candidate  scopes  of  iterations  serves  as  the 
criterion  for  selecting  the  optimal  scope.  Virtual  dimensions  are 
found  by  the  present  MODEL  Compiler  only  where  the  subscript 
expressions  used  to  reference  variable  are  of  the  form  ( I-k)  (I  is  any 
subscript,  k  is  o  or  a  positive  integer),  or  when  the  socalled 
sub  linear  or  sawtooth  indirect  indices  are  used  [I.u,  81].  The  use  of 
sublinear  indices  is  further  explained  in  the  resource  allocation 
example. 

The  MODEL  compiler  attempts  to  decompose  the  MSCC  by  deleting 
edges  which  represent  dependencies  already  assured  by  the  order  of 
iterations.  If  the  MSCC  is  not  decomposable  than  the  user  is  advised 
of  the  nodes  and  edges  of  the  MSCC.  It  is  up  to  the  user  to  verify 
that  they  do  not  represent  an  inconsistency,  such  as  circular  logic. 
The  other  possibility  is  that  they  constitute  a  set  of  simultaneous  or 
recursive  equations.  In  the  latter  case  they  are  solved  by 
incorporating  in  the  produced  program  a  selected  iterative  solution 
method  (currently  Gause-Seidel ) .  This  is  discussed  further  in 
connection  with  the  cooperative  computation  example. 
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Additional  optimization  is  performed  to  reduce  computation  time 
by  further  merging  variables  which  have  the  same  values  into  conation 
memory  space.  It  is  possible  thus  to  eliminate  statements  that  copy 
values  from  one  variable  to  another .  Transformation  of  remaining 
statements  allows  sometimes  the  elimination  of  entire  iteration  loops 
(Szymanski,  84]. 

5.4  EXTENSIONS  FOR  CONCURRENT  PROCESSING 

In  order  to  extend  the  MODEL  compiler  for  concurrent  programming, 
four  major  extensions  have  been  made. 

5.4.1  EXTERNAL  DEPENDENCY 

The  essential  difference  between  a  module  to  be  computed 
sequentially  and  concurrently  is  the  impact  imposed  by  external 
environment.  in  a  dataflow  representation,  this  impact  can  be 
represented  as  an  external  data  dependency.  An  external  dependency 
statement  (DEPENDS_0N)  is  designed  to  express  such  a  relationship. 
The  specifier  of  a  concurrent  module  (more  precisely,  a  candidate 
module  for  concurrent  execution)  must  specify  the  modules  external 
requirement  explicitly.  The  MODEL  compiler  can  then  use  the  same 
process,  as  described  previously,  to  verify  the  consistency  of 
external  data  references. 

The  external  dependency,  when  entered  into  the  array  graph,  may 
cause  creation  of  cycles.  Such  cycles  provide  a  necessary  but  not 
sufficient  condition  for  consumable  resource  deadlock.  The  MODEL 
compiler  therefore  conducts  deeper  analysis  of  initiating  and 
termination  conditions  implied  by  such  cycles.  It  can  then  determine 
whether  the  system  is  safe  of  consumable  resource  deadlocks .  Else,  it 
incorporates  an  iterative  procedure  to  solve  them,  thus  prevents  the 
consumable  resource  deadlocks.  This  is  described  in  detail  in  Chapter 
16. 


The  implementation  of  the  external  dependency  statement  is  given 
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in  Chapter  13. 

5.4.2  THE  MAIL  AND  POST  PILES 

MAIL  and  POST  are  the  two  new  file  organizations  extended  to  the 
MODEL  compiler.  The  purpose  of  introducing  the  two  files  is  to  enable 
a  module  to  communicate  with  others  concurrently.  Because  of  the 
high-level  semantics  of  these  two  file  organizations,  the  user  is 
isolated  from  the  considerations  of  global  inter- leavings  of 
computation  events.  The  same  static  view  as  composing  a  sequential 
file  is  utilized  in  composing  the  POST  and  MAIL  files.  The  semantics 
of  the  two  file  organizations  complements  the  existing  sequential  and 
index  sequential  file  organizations.  Implementation  detail  are  given 
in  Chapter  14. 

5.4.3  CONCURRENT  ISAM  PILE  UPDATES 

Sharing  an  ISAM  file  or  database  concurrently  requires  the  use  of 
record  locking  mechanism,  although  the  user  does  not  "see"  such 
low-level  detail. 

Restricted  by  the  available  operating  system,  only  one-record 
locking  is  supported.  That  is,  every  record  in  a  database  is  locked 
when  it  is  being  updated.  This  extension  ensures,  if  a  MODEL 
specification  cam  be  scheduled  into  one-record  locking  mechanism, 
proper  locking  will  be  made  automat ically  in  the  produced  PL/I 
program.  Otherwise  a  warning  message  is  issued.  The  user  is  advised 
to  incorporate  multi-record  exclusion  algorithm  manually.  The 
implementation  details  are  given  in  Chapter  15.  An  example  PL/I 
program  generated  from  a  concurrent  MODEL  specification  is  given  in 
Appendix  A. 

5.4.4  ITERATIVE  SOLUTION  TO  DISTRIBUTED  SIMULTANEOUS  EQUATIONS 

This  extension  makes  the  concurrent  MODEL  more  powerful  in  a 
distributed  environment.  The  MODEL  language  is  based  primarily  on  the 
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notion  of  equations.  In  many  applications,  problem  is  expressed  as  a 
set  of  simultaneous  equations  distributed  in  a  number  of  modules. 
These  module  must  then  cooperate  in  an  iterative  solution  process. 
Hie  MODEL  compiler  recognizes  the  need  to  use  a  single  or  multi-module 
iterative  solution  and  incorporates  the  communication  protocols  and 
algorithms  when  necessary.  Detail  can  be  found  in  Chapter  16. 


I 
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A  SECOND  EXAMPLE  -  COOPERATIVE  COMPUTATION 

6.1  SPECIFICATION  OF  INDIVIDUAL  ECONOMETRIC  MODULES 

As  mentioned  previously,  the  concurrent  computation  in  the  second 
example  represents  a  simulation  of  economic  interactions  in  the 
Pacific  Basin.  The  economies  simulated  and  their  corresponding  models 
are  those  of  the  USA,  Japan,  Taiwan,  Korea,  Philippine  and  Thailand. 
Each  model  is  represented  in  separate  module.  Due  to  space  limitation 
we  "  consider  in  Part  I  a  reduced  econometric  model,  shown  in  figure  8. 
The  complete  set  of  MODEL  equations  for  each  of  these  countries  axe 
given  in  Appendix  A. 

Although  the  example  of  econometric  model  consists  of  only  five 
equations,  it  is  generally  characteristic  of  econometric  models  and 
illustrates  the  full  models  given  in  Appendix  A.  It  contains  also 
nine  variables,  five  local  and  four  global.  The  variables  are  listed 
in  Figure  8.  Local  parameters  are  in  the  files:  Coefficient,  Control 
and  Time-series.  The  Coefficient  file  contains  the  values  of  the 
coefficients  in  the  equations,  assumed  to  have  been  previously 
computed  using  estimation  methods.  The  Control  file  contains  three 
parameters:  PD_TS,  the  number  of  periods  in  the  Time-series  file; 
PD_SIM,  the  number  of  periods  in  the  simulation  (forecast);  and  DEL, 
the  number  of  periods  from  the  beginning  of  the  time  series  to  the 
beginning  of  simulation.  The  Time-series  file  contains  historical 
values  for  the  endogeneous  variables  which  are  used  as  starting  values 
for  the  simulation.  There  are  two  files  for  exogeneous  variables 
( Local_ext>gen  and  Trade _in)  and  two  files  for  endogeneous  variables 
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( Local_solution  and  Trade _out ) .  The  former  are  prepared  as  source 
data  and  the  latter  are  computed  and  constitute  the  target  data.  This 
type  of  a  model  may  be  represented  concisely  by  the  simplified  diagram 
shown  at  the  bottom- left  of  Figure  8. 

Figure  9  shows  the  MODEL  specification  of  the  reduced  econometric 
model  of  Figure  8. 
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/*  HEADER  */ 

1  MODULE  NAME:  A; 

2  SOURCE  FILES:  TIME_SERIES ,  CONTROL,  COEFFICIENTS,  TRADE_IN , 

LOCAL_EXOG; 

3  TARGET  FILES:  LOCAL_SOL,  TRADE.OUT; 

/*  DATA  DESCRIPTIONS  */ 

4  1  CONTROL  IS  FILE, 

2  C_RECORD  IS  RECORD 

3  ( PD_TS , PD_SIM , DEL )  IS  FIELD  (PIC 999*); 

5  1  COEFFICIENTS  IS  FILE, 

2  COEF_RECORD  IS  RECORD 
3  C( 13 )  IS  FIELD  (DEC  FLOAT)} 

6  1  TIME_SERIES  IS  FILE, 

2  TS_RECORD  (1:20)  IS  RECORD 

3  (TS_CONS,TS_INV,TS_GDP,TS_VX,TS_PM)ARE  FIELDS  (DEC  FLOAT); 

7  1  LOCAL_EXOG  IS  FILE, 

2  EX_REC  (1:30)  IS  RECORD 
3  (II, GOV)  ARE  FIELDS  (DEC  FLOAT); 

8  1  TR_IN  IS  FILE, 

2  TR_IN_RECORD  (1:30)  IS  RECORD 
3  (VM,PX)  ARE  FIELD( DEC  FLOAT); 

9  1  TR_OUT  IS  FILE 

2  TR_OUT_RECORD( 1 : 30  )  IS  RECORD 
3  ( VX,PM)  ARE  FIELD( DEC  FLOAT); 

10  1  LOCAL_SOL  IS  FILE, 

2  SOL_RECORD  (1:30)  IS  RECORD 
3  ( CONS, INV, GDP)  ARE  FIELDS  (PIC’BB( 6 )9 . V( 6 )9 ’ ); 

/♦DATA  PARAMETERS*/ 

11  SIZE . SOL_RECORD  -  PD_SIM; 

12  SIZE . TS_RECORD  -  PD_TS ; 

13  T  IS  SUBSCRIPT; 

/*  EQUATIONS  ♦/ 

14  CONS(T)  -  IF  T  >  1  THEN  C( 1 )  +  C(2)*GDP(T)+  C( 3  )*C0NS(T-1 ) 

ELSE  TS_CONS( T+DEL ) ; 

15  INV(T)  -  IF  T  >  1  THEN  C(4)  +  C(5)*GDP(T)+  C(  6  )*GDP(T-1 )  + 

C(  7  )*II(T) 

ELSE  TS_INV(  T+DEL); 

16  GDP(T)  =»  IF  T  >  1  THEN  CONS(T)  +  INV(T)  +  VX(T)+  GOV(T)  -  VM(T) 

ELSE  TS_GDP(  T+DEL); 

17  VX(T)  -  IF  T  >  1  THEN  C(  8  )  +  C(9)*PX(T)+  C(  10 )  »GDP(  T-l ) 

ELSE  TS_VX(  T+DEL ) ; 

18  PM(T)  -  IF  T  >  1  THEN  C(  11 )  +  C(  12  )*PM(  T-l )+  C(13)*VM(T) 

ELSE  TS_PM( T+DEL); 

/♦EQUATIONS  DEFINED  EXTERNALLY*/ 

19  TR_IN_RECORD(T)  -  DEPENDS_ON( TR_OUT_RECORD( T )  ) ; 


PIGURE  9.  Specification  of  a  Reduced  Econometric  Model  of  a  Country. 


The  header  at  the  top  of  the  figure  identifies  the  name  of  the 
program  module  to  be  generated  (A),  and  the  names  of  the  five  source 
and  two  target  files.  The  description  of  the  organization  of  the 
files  follows.  The  variable  sizes  of  dimensions  of  data  arrays  are 
defined  in  data  parameter  equations  ( statements  11  to  13 ) .  Namely, 
the  size  or  range  of  the  lowest  order  ( right  most )  dimension  of  the 


structure  TS_RECORD  xs  equal  to  PD_TS,  and  the  number  of  repetitions 
of  the  local  solution  records,  i.e.  the  periods  of  simulation,  is 
equal  to  PD_SIM.  T  is  a  subscript  which  denotes  the  period  number  of 
the  simulation.  The  specification  concludes  with  the  five  econometric 
equations  in  statements  14  to  18.  The  values  of  the  variables  for  the 
periods  prior  to  start  of  simulation  (T<*DEL )  come  from  the 
Time_series  file.  Otherwise  they  are  defined  by  the  respective 
expression . 

An  examination  of  the  equations  in  Figure  9  reveals  that 
statements  15  and  16  form  a  set  of  simultaneous  equations.  If  the 
external  dependency  equation  19  is  included,  it  forms  smother  set  of 
simultaneous  equations  with  statements  17  and  18.  The  equations  which 
specify  in  detail  the  external  dependency  are  in  external  modules  in 
the  global  configuration.  The  cooperation  of  the  Configurator  and  the 
MODEL  Compiler  is  necessary  in  implementing  a  solution  process.  This 
is  further  discussed  in  the  next  chapter. 


6.2  CONFIGURING  A  MULTI -ECONOMETRIC  MODEL  SYSTEM 

There  sire  two  problems  in  synthesizing  selected  individual 
country  models.  First,  the  economies  of  the  selected  countries  are 
also  highly  interdependent  on  the  economies  of  other  countries  not 
included  in  the  study,  and  these  interdependencies  must  be  added. 
Second,  the  data  in  the  communicating  files  must  be  compatible  in 
meaning  as  well  as  structure.  For  instance,  the  periodicity  of  the 
time  series  variables  (i.e.  quarterly,  annual,  etc.)  and  currency 
units  may  vary  from  model  to  model.  Also  the  export  variable  (VX)  in 
each  model  must  be  disaggregated  to  determine  the  appropriate  portions 
of  the  entire  export  of  one  country  which  become  imports  to  each  of 
the  other  countries.  These  portions  are  computed  in  Project  LINK  on 
the  basis  of  the  most  recent  bilateral  trade  share  statistics.  The 
portions  of  exports  from  each  country  to  one  country  axe  sunned  to 
form  its  total  import  (VM). 
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of  exports  from  all  the  other  countries.  This  interfacing  function 
forms  an  additional  module  called  WORLD.  It  can  be  viewed  as  a  case 
of  allocation  of  consumable  resources  -  with  source  data  on  exports 
viewed  as  requests  for  target  data  on  imports.  The  WORLD  model  is 
extensive  and  is  omitted  here  in  the  interest  of  brevity. 


The  configuration  synthesizing  the  countries  in  the  region  is 
shown  in  Figure  10(a). 


CONFIGURATION:  PACIFIC; 

Fs  USA_EXDG,  USA_TR_IN  ORG:  MAIL 
-»  M:  USA 

->  F:  USA_SOL,  TRjOUT  ORG:  MAIL; 

P:  JAP  JEXDG,  JAP_TR_IN  ORG:  MAIL 
->  M:  JAP 

->  F:  JAP_SOL,  TRJOUT; 

F:  TWN  JEXDG,  TWN_TR_IN  ORG:  MAIL 
-»  M:  TWI 

->  F:  TWN_SOL,  TRjOUT; 

F:  PHI_EXDG,  POI_TR_IN  ORG:  MAIL 
->  M:  PHI 

->  F:  PHIjSOL,  TR_  OUT; 

P:  THIjnOOG,  THI_TR_IN  ORG:  MAIL 
-»  M:  THI 

->  F:  THI_SOL,  TR.OUT; 

F:  KRA JEXDG,  KRA_TR_IN  ORG:  MAIL 
->  M:  KRA 

-»  F:  KRA_SOL,  TR_OUT; 

F:  MRU) JEXDG,  TR_OUT  ORG:  MAIL 
->  M:  WRID 

->  F:  WRLD_SOL,  TR_IN  ORG:  POST; 

F:  TR_IN 

->  F:  USA_TR_IN,JAP_TR_IN,TVW_TR_IN,PHI_TR_IN,KRA_TR_IN,THI_TR_IN; 


FIGURE  10(b).  Configuration  Specification  of  Pacific  Basin  Model 


This  cooperative  computation  scheme  assumes  the  use  of  a  computer 
network.  Each  model  is  computed  in  the  computer  of  it’s  respective 
"owner"  organization.  Solutions  are  conducted  in  parallel  in  the 
respective  computers .  The  distributed  approach  needs  not  be  justified 
by  reductions  in  cost  of  realizing  the  computation,  but  by  the 
convenience  to  the  developers  which  contributes  to  an  improved  system 


CHAPTER  7 

DISTRIBUTED  SOLUTION  OP  SIMULTANEOUS  EQUATIONS 


As  already  mentioned  in  Section  4.3,  the  MODEL  compiler 
recognizes  maximally  strongly  connected  components  ( MSCC )  in  an  array 
graph  and  performs  analysis  and  design  of  solution  methods. 
Essentially  it  incorporates  in  the  produced  program  a  Gauss-Seidel 
iterative  solution  method  [Greenberg,  81].  The  success  of  the 
computation  depends  on  convergence  of  the  solution.  The  user  may 
optionally  specify  convergence  conditions  and  maximum  number  of 
iterations,  otherwise  the  default  value  is  used  (presently  100 
iterations).  The  generated  code  includes  printing  of  a  defined  error 
message  if  convergence  in  not  attained. 

In  the  above  example  there  is  one  cycle  which  is  local  to  each 
module,  consisting  of  equations  15  and  16  and  the  variables  INV  and 
GDP  (see  Figure  9).  There  is  another  MSCC,  much  more  complicated, 
that  involves  all  the  modules  and  in  each  module  it  includes  equations 
17  and  18,  the  external  dependency  equation  19,  the  variables 
PX,VM,VX,PM  and  the  records  TR_IN_RECORD  and  TR_0OT_REC0RD .  The 
existence  of  an  external  dependency  in  a  MSCC  in  a  given  module  means 
that  there  are  other  modules  which  participa  a  in  the  solution.  These 
modules  are  not  known  at  the  time  that  a  program  is  generated  by  the 
MODEL  Compiler.  Therefore  it  was  necessary  to  devise  an  algorithm  to 
be  incorporated  in  each  of  the  modules  to  cooperate  in  the  solution 
with  external  modules,  without  knowing  their  identity,  number  or 
interconnection  pattern. 
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The  method  applied  by  the  MODEL  Compiler  is  as  follows.  In  each 
module  the  MSCC  with  external  dependencies  includes  record  nodes. 
They  are  represented  in  the  generated  program  by  read  or  write 
operations.  All  the  other  variables  in  the  Msec  in  an  individual 
module  are  solved  iteratively  locally.  The  solutions  of  each  module 
of  the  external  variables  (VX,PM)  are  communicated  to  respective  other 
modules  repeatedly  until  global  convergence  is  attained.  This  is 
illustrated  in  Figure  10(a)  showing  the  circular  connection  of  module. 
Results  of  each  global  iteration  are  being  conmunicated  between 
modules  by  the  respective  reading  and  writing  operations.  The  WORLD 
module  uses  all  the  values  of  export  ( TR_OOT )  from  (I-l)th  iterations 
of  the  iterative  solution  for  evaluation  of  values  of  import  (TR_IN) 
for  Ith  iteration. 

In  the  case  of  an  iterative  solution  involving  a  number  of 
modules,  the  MODEL  Compiler  also  generates  a  protocol  in  the  produced 
program  to  determine  when  overall  convergence,  or  excess  of  the  number 
of  iterations,  has  been  attained,  and  the  iterative  solution  should  be 
terminated.  Such  protocol  is  generated  locally  in  each  module  program 
without  knowledge  of  other  modules  involved.  The  problem  is  similar 
to  that  of  distributed  termination  [Dijkstra,  83;  Francez  and  Rodeh, 
82;  Topor,  84].  In  our  solution  however  we  want  to  add  termination 
data  only  to  records  being  exchanged  between  modules.  Consequently, 
we  may  not  assume  that  new  comnunication  channels  can  be  added  as  in 
[Dijkstra,  83]  or  that  existing  channels  are  bilateral  as  in  [Francez 
and  Rodeh,  82;  Topor,  84],  The  graph,  although  never  constructed  or 
known  explicitly,  consists  of  nodes  representing  modules  and  directed 
edges  which  represent  the  records  being  exchanged  between  modules. 

The  algorithm  is  incorporated  in  the  module  programs.  Each 
record  containing  values  of  variable  from  one  module  to  another  has  a 
token  added  to  it.  The  network  may  be  viewed  as  a  directed  graph, 
where  the  modules  form  nodes  and  where  the  tokens  are  propagated  along 
the  edges.  The  network  forms  a  maximally  strongly  connected  component 
as  illustrated  in  Figure  10(a).  Each  node  determines  the  value  of  the 
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token  sent  either  as  equal  to  the  minimum  on  the  values  of  the 
incoming  tokens  plus  1  or  if  it  has  not  locally  reached  convergence 
( or  exceeded  the  maximum  number  of  iterations )  then  1 .  This 
information  is  propagated,  one  node  on  each  iteration,  throughout  the 
network.  If  the  diameter  of  the  network  is  D,  it  takes  D  iterations 
until  the  information  reaches  the  furthermost  module.  In  this  manner, 
D+l  iterations  after  all  the  module  have  reached  convergence,  the 
value  of  the  tokens  would  be  D+l  in  all  the  modules  and  they  all 
terminate  iterations  simultaneously. 

Description  and  derivation  of  the  termination  algorithm  are  given 
in  section  16.2  ( Part  III).  Implementation  techniques  used  to 
incorporate  the  algorithm  is  described  in  section  16.3  (Part  III). 


CONCLUSION  AND  FUTURE  RESEARCH 


As  mentioned  earlier,  this  dissertation  intended  to  make  two 
points.  Pirst  that  the  use  of  a  new  class  of  languages  in  concurrent 
programming,  which  we  characterize  as  very  high  level,  equational, 
definitional,  nonprocedural  or  dataflow,  is  natural  and  effective. 
The  effectiveness  is  justified  by  the  number  of  definitional 
statements  in  the  first  example,  especially  the  R  module.  The  R 
module  uses  20  statements  for  defining  the  "maximum  claim”  algorithm 
( for  resource  allocation  problems  in  general > .  The  naturalness  can  be 
justified  by  the  second  example  which  takes  almost  literally  the 
economectric  equations  from  the  LINK  project  and  the  MODEL  compiler 
translates  them  into  a  distributed  operational  system.  Also,  the 
studies  done  by  [Cheng,  83]  shows  evidences  of  naturalness  and 
effectiveness  in  other  aspects . 


Second,  that  am  automated  program  design  methodology  can  verify 
the  specification  and  translate  the  specification  into  efficient 
concurrent  computation  using  existing  computer  technology.  The 
presentation  through  use  of  characteristic  examples  was  intended  to 
convey  the  flexibility  and  practicality  of  the  programming  approach  in 
present  day  applications.  The  current  implementation  relies  on  modem 
operating  systems  and  computer  architecture,  currently  VMS  and 
VAX-750.  Theoretically  the  two  system  can  be  implemented  on  UNIX,  or 
any  other  machines. 

In  reviewing  the  new  concepts  in  computer  architecture  we  believe 


that  a  similar  methodology  would  be  devised  in  the  future  for 
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implementing  parallel  processing  in  new  generations  of  computers.  The 
independence  of  the  language  from  the  object  computer  architecture 
makes  it  a  good  candidate  for  use  for  future  computer  architecture. 
The  dataflow  approach  exposes  the  possible  parallelisms  and  can  be 
used  for  programning,  for  instance,  for  dataflow  computer  machines 
[Gokhale,  83]. 

As  noted,  the  research  described  in  this  dissertation  has  3till 
unsolved  problems.  The  future  research  under  this  main  direction  is 
summarized  below: 

i)  the  checking  of  convergence  and  parallel  processing  of  recursive 
functions, 

ii )  development  of  a  system  that  will  evaluate  timing  between 
receiving  and  sending  of  records,  to  verify  if  real  time  system 
timing  constraints  are  satisfied,  and  to  modify  the  design  if  not 
[Tseng,  83], 

iii)  further  extend  the  semantic  checking  of  a  specification  on  MODEL 
specification  level  and  configuration  level, 

iv )  further  automate  program  generation  by  generating  external 
dependencies  automatically, 

v)  more  effective  file  organizations  for  general  applications, 

|  vi)  more  flexible  definition  of  module  execution  time  and  more 

verification  on  execution  sequence  of  a  configuration,  and 
vii)  automatic  generation  of  query  sub-system  by  the  Configurator  to 
facilitate  on-line  configuration  information  retrieval  by  using 
«  some  functional  languages,  such  as  PROLOG  or  LISP. 


Also,  the  entire  problem  of  automatic  partitioning  of  a 


computation  into  modules  and  files  to  attain  a  high  degree  of 
parallelism  is  an  as  yet  unsolved  one  which  is  assuming  major 
importance  in  Computer  Science. 


PART  II 


THE  CONFIGURATION  SYSTEM 
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CHAPTER  9 


INTRODUCTION  TO  THE  CONFIGURATOR 

The  function  of  the  Configurator  is  to  synthesize  program  modules 
and  data  files  that  may  be  operated  concurrently  and/or  distributed 
geographically.  Establishing  conmunications  between  modules  and 
integrating  them  into  a  structured  system  remains  a  complex  and  error 
prone  task.  We  refer  to  this  task  as  to  the  configuration  of  a 
system.  The  Configurator  assists  the  user  to  verify  the  consistency 
and  completeness  of  the  system  and  to  synthesize  the  components  into 
an  integrated  system. 


9.1  THE  LANGUAGE  -  CSL 

csl,  standing  for  ggofigucation  gpecification  Language,  is 
designed  for  describing  a  network  of  modules  connected  through  data 
files.  It  is  a  "path  language",  because  it  describes  a  network  by 
listing  its  paths. 

CSL  aims  at  a  broad  range  of  applications,  which  include 
configurations  of  sequential,  concur rent/ sequential,  and  interactive 
systems.  TO  avoid  repeating  paths  in  a  CSL  specification,  only 
nonredundant  paths  have  to  be  specified.  The  system  automatically 
determines  all  the  paths  whose  existence  can  be  derived  from  combining 
those  that  are  explicitly  specified  by  the  user. 
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9.2  THE  PROCESSOR  -  CONFIGURATOR 

The  Configurator  is  the  compiler  of  CSL.  As  mentioned  in  Chapter 
3  (Part  I),  the  Configurator  has  five  functions:  checking  the  input 
CSL  specification,  scheduling  execution  of  modules,  evaluating 
diamters  of  strongly  connected  components,  generating  JCL  and  PL/ I 
programs  and  generating  user  system  documentation. 

Chapter  11  of  this  Part  is  devoted  to  presenting  the  working 
principles  and  translation  mechanisms  of  the  Configurator. 


THE  CONFIGURATION  SPECIFICATION  LANGUAGE 

In  this  chapter,  we  give  the  syntax  and  semantics  of  CSL 
statements  for  describing  a  system  configuration. 

10.1  OVERALL  GRAPH  DESCRIPTION 

A  multi-module  system  may  have  sequential,  concurrent  and/or 
distributed  components.  It  is  represented  as  a  network  of  modules  and 
files.  It  can  be  visualized  as  a  graph  where  the  modules  and  files 
sure  nodes  and  the  relations  of  modules  consuming  or  producing  files 
are  edges.  A  CSL  description  of  a  network  consists  of  a  set  of 
statements  describing  the  paths  in  the  network.  Each  path  is  defined 
in  a  statement  as  a  chain  of  nodes  connected  by  edges. 

The  overall  structure  of  a  configuration  specification  is: 

<CONFSPEC> : CONFIGURATION:  <  IDENTIFIER) 

[(  DIAM  :  < INTEGER)  )]  ;  < STATEMENTS) 

<  STATEMENTS  >::=”<  STATEMEJ/T  >  [  ;  <  STATEMENT  >  ]  *  ; 

< STATEMENT)  :  :  =« < PATH_STATEMEOT >  |  < SYNONYM_STMT> 

FIGURE  11.  Syntax  structure  of  a  CSL  specification 

A  specification  has  a  number  of  statements,  first  it  has  a  name  - 
am  identifier,  which  is  a  string  of  letters  and  digits,  beginning  with 
a  letter.  The  length  of  an  identifier  is  limited  to  eight  characters . 

The  name  of  the  configuration  may  be  optionally  followed  by  a 
parenthesized  parameter  of  the  configuration,  called  diameter.  The 
diameter  is  needed  only  in  the  cases  where  there  exist  cycles  in  the 


configuration  that  represent  communicating  modules  that  jointly 
perform  a  solution  of  simultaneous  equations.  Namely,  where  the 
simultaneous  equations  are  distributed  over  all  the  modules  in 
respective  cycles.  In  such  a  case ,  it  is  necessary  to  evaluate  the 
maximum  distance  between  modules  in  order  to  have  orderly  termination 
of  the  iterative  solution.  The  Configurator  calculates  the  diameter 
automatically  for  each  strongly  connected  component  (i.e.  cycles)  in 
the  configuration  graph.  The  user  may  have  better  insight  and  wish  to 
over-ride  the  automatically  evaluated  diameter.  1*113  is  further 
discussed  in  section  10.8. 

Next,  there  are  two  types  of  statements  -  to  describe  paths  and 
synonyms . 

< PATH_STATEMENT >  : :-< NODES >  [->  < NODES >  ]* 

FIGURE  12.  Syntax  of  a  path  statement 

The  path  statement  is  used  to  describe  a  path  in  the 
configuration.  The  path  statement  consists  of  a  chain  of  lists  of 
nodes  connected  by  the  symbol  ”— > "  which  represents  an  edge.  A  list 
consists  of  one  or  more  nodes.  A  path  statement  may  contain  only  one 
list  of  nodes.  In  such  a  case,  the  statement  merely  declares  the 
existence  of  nodes. 

Example  10.1. 

M:  A  ->  F:  U,V  ->  Ms  B  ->  P:  W,X; 

F:  V  ->  M:  C  ->  F:  W,X; 

The  above  CSL  statements  describe  the  inter-connection  between 
three  module  nodes(A,B,C)  and  four  file  nodes(U,V,W,X).  The 
corresponding  graph  is  shown  below. 
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We  will  say  that  the  files  coming  into  a  module  as  being 
"consumed"  by  the  module  and  the  files  going  out  of  a  module  as  being 
"produced"  by  the  module. 

A  more  detailed  description  of  the  path  statement  is  given  in  the 
following  section. 

The  SYNONYM  statement  is  used  to  unify  differently  named  nodes 
into  one  node,  when  these  nodes  actually  correspond  to  only  one 
physical  entity  in  a  configuration. 

The  syntax  diagram  of  a  synonym  statement  is  as  follows. 

<SYNONYM_STMT>  ::-S:  <NAME> ,  <NAME>  [,  <NAME> ] *; 

<NAME>  j j-  [  < IDENTIFIED . ]  (IDENTIFIED 

FIGURE  13.  Syntax  of  a  Synonym  Statement 

Sample  10.2. 

S:  A,  B,  C; 


specifies  that  nodes  A,  B  and  C  correspond  to  one  physical  entity.  A 
more  detailed  description  of  the  SYNONYM  statement  is  given  in  section 


10.2  NODES  IN  A  PATH  STATEMENT 


The  syntax  diagram  of  a  node  description  is: 

< NODES >  : <MDDOLE_NODES>  |  <FILE_N0DES> 

< MODULE_NODES >  :  M  :  [  +  ]  IDENTIFIER)  [ < M_ ATTRI BUTES > ] 

,  [,[+]  < IDENTIFIER)  [<M_ATTRIBUTES)]]* 

I  <  FI  LE_N0DES  >  :  :-  F  :  f  <QUALIFIER>  .  ]  <IDENTIFIER>  [  <  F_ ATTRI  BOTES  >  ] 

C / [ (QUALIFIER) . ] < IDENTIFIER)  [ <F ^ATTRIBUTES) ] ]* 

FIGURE  14.  Syntax  of  a  configuration  node 

There  are  trwo  kinds  of  nodes  in  a  configuration:  MODULE  nodes 

and  FILE  nodes.  A  list  of  MODULE  or  FILE  nodes  is  prefixed  by  M  or  P 
respectively.  Furthermore,  a  MODULE  node  nay  be  prefixed  by  a  "+" 
symbol  to  indicate  that  the  module's  execution  may  be  "added”,  i.e. 
initiated  manually,  rather  them  automatically. 

A  FILE  node  can  also  be  prefixed  by  the  producer  or  consumer 
MODULE  name,  to  differentiate  between  files  with  the  same  name. 

A  node  may  have  a  number  of  optioned,  attributes,  such  as  type 
(described  further),  physical  file  name,  record  size  and  device 
description.  When  an  attribute  is  not  specified,  a  default  value  is 
assigned  to  it. 


10.3  MODULE  NODE  ATTRIBUTES 


The  syntax  diagram  of  a  module  node  attribute  is: 


<M_ATTRIBUTE)  : :-  [ <M_TYPE> ]  [ <PHYSICAL_NAME> ] 

< M_TYPE >  :  :=»  (  TIP  :  <NTP>  ) 

<MTP>  MDL  |  GRP  |  MAN 

<PHYSICAL_NAME>  : :»  -  [ <NETWK_ADDR> ][ < DIRECTORY) ][ <P_NAME> ] 

[ (SUFFIX) ]  C‘VERSION>] 

<NETWK_ADDR>  ::-  (IDENTIFIER)  :: 

< DIRECTORY)  : :-  (  < IDENTIFIER)  [ . < IDENTIFIER) ]*  ) 

<P_NAME>  ::-  <IDENTIPIER> 

< SUFFIX)  ::-  .  < IDENTIFIER) 

(VERSION)  : :”  < INTEGER) 

FIGURE  15.  Syntax  of  an  attribute  of  a  module 


Underlined  is  the  default  attribute. 
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10.3.1  MODULE  TYPE  ATTRIBUTE  (M_TYPE) 

A  MODULE  node,  in  general,  corresponds  to  a  user  defined  function 
which  can  be  a  program,  a  terminal,  or  a  set  of  programs  and 
terminals .  A  module  may  consume  and  produce  f ile( s ) .  A  module  of 
type  MDL,  corresponds  to  an  executable  program  produced  either  by  the 
MODEL  compiler,  or  by  a  programmer.  A  node  of  type  GRP  is  a 
sub-system  which  consists  of  a  group  of  lower  level  modules  which  may 
also  consume  and  produce  file(  s ) .  It  is  represented  as  a  single 
module  node.  This  feature  cam  be  used  in  developing  large  systems  to 
represent  a  hierarchy  existing  inside  a  system.  The  use  of  GRP  type 
nodes  can  also  improve  the  readability  of  a  CSL  specification. 

The  analysis  and  scheduling  phases  in  the  Configurator  assume 
that  all  the  modules  re  ATOMIC,  meaning  that  they  acquire  all  their 
files  at  the  beginning  and  release  them  at  the  end  of  processing. 
This  is  generally  true  for  the  programs  generated  by  the  MODEL 
compiler.  However,  a  GRP  node  is  generally  not  ATOMIC,  in  that  its 
constituent  module  nodes  acquire  and  release  files  according  to  the 
way  they  are  scheduled  by  the  Configurator.  The  use  of  non-atomic 
module  nodes  may  cause  loss  of  efficiency  in  scheduling  and  loss  of 
the  ability  for  conducting  various  consistency  checking.  The 
alternative  for  the  user  is  to  provide  more  detailed  information  by 
replacing  a  non-atomic  node  by  its  more  elementary  atomic 
constituents . 

A  node  representing  manual  interactions  -  MAN,  corresponds  to  a 
terminal.  A  MAN  module  consumes  a  file  produced  by  another  module, 
displays  it  on  the  screen  of  the  terminal  and  produces  a  file 
corresponding  to  data  keyed  in  by  the  terminal  operator.  Introduction 
of  the  MAN  type  allows  represent  also  manual  interactions  in  a 
configuration.  The  MAN  type  informs  the  Configurator  to  generate 
special  commands  for  connecting  the  I/O  channels  to  the  keyboard  and 
screen  of  a  terminal. 


10.3.2  PHYSICAL  NAME  ATTRIBUTE  ( PHYSICAL_NAME ) 


The  < PHYSICAL_NAME >  attribute  binds  the  logical  name  given  by  the 
identifier  of  a  node  to  a  physical  name  of  a  program  or  a  data  file 
existing  in  the  network.  The  syntax  of  the  conmand  language  for 
!  Digital  Equipment  Corporation's  VAX/VMS  operating  system  is  followed 

here. 

The  physical  name  provides  an  address  in  a  computer  network,  and 
in  a  user's  directory.  It  may  optionally  have  a  suffix  indicating  the 
contents  of  the  physical  entity  (explained  below)  and  a  version 
number. 

< NETWK_ADDR >  is  the  address  in  a  computer  network.  Hie  addresses 
should  be  known  to  the  VMS  network  communication  package  which  can 
then  setup  conaminications  between  the  specified  sites.  The  default  is 
the  local  site  where  the  Configurator  is  run. 

< DIRECTORY >  is  the  name  of  a  directory  or  sub-directory  of  user's 
account.  Hie  default  is  the  root  directory. 

<P_NAME>  specifies  a  physical  entity  in  the  directory.  It  may 
differ  from  a  logical  name  adding  flexibility  to  naming  in  CSL. 
<P_NAME>  is  an  identifier  up  to  10  characters  long.  Hie  default 
<P_NAME>  is  the  logical  name. 

<SUFFIX>  is  a  three  character  name  attached  to  the  P_NAME .  it 
may  be  used  to  indicate  the  type  of  data  stored  in  the  identified 
file.  The  default  is  "  "(blank).  A  user  can  add  an  arbitrary  suffix 
to  a  P_NAME.  Some  of  the  predefined  suffix  names  and  their  meanings 
in  VMS  are  summarized  below. 

PLI  — >  PL/ I 
FTN  — >  FORTRAN 
PAS  — >  PASCAL 
DAT  — >  Data  file 

LIS  — >  Listing  file  produced  by  compilers 
COM  — >  VMS  comnand  program 
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< VERSION >  is  an  integer  and  is  used  to  indicate  a  particular 
version  of  a  file  on  a  computer.  On  VAX,  the  VMS  retains  old  versions 
of  a  file  which  have  to  be  explicitly  deleted.  One  cam  address 
different  versions  of  a  file  by  specifying  version  numbers.  The 
default  is  the  most  recent  version  of  the  file. 

Example  10.3. 

M:  P1-UPOIN-750 : :( YUAN. TEMP )TEST.PLI; 10 

specifies  that  a  module  node  with  logical  name  PI  corresponds  to 
a  file  in  a  computer  network  with  a  computer  address  "UPENN-750",  in 
directory  [YUAN. TEMP]  bounded  to  the  physical  name  TEST  with  suffix 
PLI  and  version  number  10. 


10.4  FILE  NODE  ATTRIBUTES 


The  syntax  diagram  of  the  attributes  of  a  PILE  node  is  as 
follows. 


<F_ATTRIBUTE> : [ <F_TYPE> ]  [ < PHYSICAL-NAME > ] 

[< RECORD-SIZE >]  [<F_DEVICE>] 

<F_ TYPE>  j  :=*  (  TYP  :  <FTP>  ) 

<FTP>  2&M  j  ISAM  |  POST  !  MAIL 

<  RECORD— SIZE  > : RS :  < INTEGER) . 

<F_ DEVICE >  :  :=»  DEV:  DISK  |  TAPE 

FIGURE  16.  Syntax  of  attribute  description  of  a  file  node 


A  PILE  node  corresponds  to  am  entire  logical  data  structure 
consumed  or  produced  by  a  module. 


10.4.1  FILE  TYPE  ATTRIBUTE  ( F_ TYPE ) 

The  F-TYPE  attribute  determines  the  organization  of  a  file  and 
thus  the  use  of  the  file  in  the  network. 

A  SAM  file  is  a  data  file  existing  as  one  entity.  Namely,  if  the 
file  is  exchanged  between  modules,  the  file  must  be  completely 


produced  by  a  module  before  it  can  be  consumed  by  other  modules.  In  a 
path 

M:M1— >F:F1  (TYPtSAM)— >M:M2, 

let  the  starting  time  of  the  modules  Ml  and  M2  be  denoted  by  tsl  and 
ts2,  and  ending  time  by  tel  and  te2,  then  the  path  implies  tel  <  ts2. 

In  the  current  version  of  the  system,  it  is  implemented  as  a 

sequential  file  residing  on  disk  or  tape,  and  thus  a  SAM  file  is 

retained  even  after  it  hats  been  consumed.  Whether  a  file  is  on  disk, 
or  tape  must  be  defined  in  the  F_DEVICE  attribute,  if  the  file  is  on 
tape,  a  number  of  modules  may  consume  it  only  in  sequence  (with  a 

rewind  in  between).  If  the  file  is  on  disk,  it  may  be  consumed 

concurrently  by  a  number  of  modules.  SAM  is  the  default  value  of  the 
P_TYPE  attribute. 

An  ISAM  file  is  a  set  of  data  whose  individual  units  ( records ) 
can  be  consumed  and  produced  concurrently  by  many  modules.  Each 
record,  except  when  it  is  redefined  (updated)  by  producing  modules,  is 
retained  in  the  file  even  after  it  hats  been  consumed,  there  are  no 
timing  restrictions  on  modules  connected  through  an  ISAM  file.  An 
ISAM  file  is  implemented  as  an  indexed  sequential  file  indexed  by 
keys,  randomly  accessible  and  can  reside  only  on  disk.  An  ISAM  file 
may  have  a  number  of  separate  versions  ( “older"  and  "newer" ) 
represented  by  same  named  ( or  synonymous )  ISAM  file  nodes  connected  by 
edges,  indicating  sequentiality  between  producing  and  consuming 
respective  versions.  In  a  path: 

M:M1  ->  F:P1  (TYP:ISAM)  ->  P:P2  (TYP:ISAM)  ->M:M2, 
then  PI  and  P2  are  two  versions  of  the  same  file  amd  tel  <  ts2. 

This  is  described  further  in  section  10.5  which  discusses  the 
semantics  of  the  edges. 

A  MAIL  file  represents  data  being  coimnunicated  between  one  or 
several  concurrent  producing  and/or  consuming  modules.  Units  of 
communication  called  records  are  produced  one  or  several  at  a  time, 
amd  queued  in  the  order  of  their  times  of  production.  The  records  are 


serves  also  as  a  queue  when  there  are  several  producer  and/or  consumer 
modules.  The  production  and  consumption  of  records  may  be  concurrent 
and  is  automatically  synchronized,  therefore  synchronization  need  not 
concern  the  user  of  CSL.  in  a  path: 

MiMl  ->  FsFl  (T*P:MAIL>  ->  M:M2, 
it  is  required  that  tsl  >  ts2  &  te2  <  tel. 

Requirements  of  compatibility  between  specifications  of 
interfacing  files  are  described  in  section  10.6. 

A  POST  file  also  represents  data  being  communicated  in  record 
units,  similar  to  a  MAIL  file.  However,  a  POST  file  must  consist  of 
records  containing  addresses  of  their  destinations.  Each  record  is 
automatically  delivered  to  the  indicated  destination  -  a  MAIL  file.  A 
POST  file  is  produced  by  only  one  module  but  it  cam  be  connected  to 
any  number  of  destination  MAIL  files  being  consumed  by  different 
modules.  This  is  further  explained  in  connection  with  discussion  of 
the  edges.  The  POST  file  records  also  have  a  compatibility 
requirement  described  in  section  10.6. 

The  address  provided  in  records  in  a  POST  file  must  be  the 
physical  name  of  the  destination  file.  The  construction  of  a  physical 
name  is  as  follows. 

i)  For  MAIL  files  that  are  source  of  a  module  which  is  not  prefixed 
by  "+",  the  physical  name  is:  < logical  name > S_MBX 

ii)  For  MAIL  files  that  are  sources  of  a  "+"  module,  the  physical 
name  is  :  <logical  name>S_MBX<creation  time>. 

In  this  way,  the  system  can  distinguish  the  different 
instances  of  a  "+"  module  which  uses  the  same  module  and  file 
names.  In  the  MODEL  specification,  the  user  can  use  the  function 
PHYS_NAM( logical  name),  which  returns  a  physical  name  bound  to 
the  logical  name  at  runtime,  to  define  an  address  field  in  a  POST 


The  selection  of  file  types  is  based  on  the  requirements  in  the 
configuration  for  concurrency,  distributed  operations  or  supply  of 
data.  These  are  discussed  in  further  detail  in  section  10.6. 

Note  on  implementation: 

The  file  types  discussed  above  can  be  implemented  in  many  ways, 
depending  on  the  operating  system  features  available  on  the  target 
computer .  The  SAM  and  ISAM  correspond  naturally  to  sequential  and 
index  sequential  file  organizations  supported  by  commercially 
available  operating  systems.  Under  VAX- VMS ,  the  MAIL  and  POST  files 
have  been  implemented  via  the  mailbox  facility.  Under  different 
operating  systems  the  implementation  might  be  totally  different. 


10.4.2  PHYSICAL  NAME  ATTRIBUTE  ( PHYSICAL_NAME ) 

This  attribute  has  the  same  syntax  and  semantics  as  the  physical 
name  attribute  of  a  MODULE  node,  described  in  section  10.3. 


10.4.3  RECORD  SIZE  ATTRIBUTE  ( RECORD_SIZE ) 

This  attribute  is  only  required  for  MAIL  files.  It  defines  the 
maximum  size  of  records.  The  default  is  300  characters  (bytes). 


10.4.4  PILE  DEVICE  ATTRIBUTE  (F_DEVICE) 

This  attribute  is  used  only  for  SAM  files.  The  default  is  DISK. 

This  attribute  allows  the  Configurator  to  determine  whether  a 
file  can  be  consumed  concurrently  (DISK  files)  or  have  to  be  consumed 
sequentially  (TAPE  files). 
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10.5  EDGES 


An  edge  represents  consumption,  production  or  causality 
relationships  between  two  nodes.  The  direction  of  an  edge  is 
indicated  by  the  •*->M  symbol  in  a  CSL  statement. 


node 

» - f  edge 

|  SOURCE  | - 

> . -  . . ♦ 


node 

-i - - . 

>  |  TARGET  | 

4 - f 


This  section  discusses  the  meaning  of  an  edge,  depending  on  the 
attributes  of  its  source  and  target  nodes. 

i)  If  the  source  is  a  module  node  and  the  target  i3  a  file  node,  an 
edge  indicates  that  the  file  is  produced  by  that  module. 

ii)  If  the  source  is  a  file  node  and  the  target  is  a  module  node,  an 
edge  means  that  the  file  node  is  consumed  by  that  module. 

iii)  If  the  source  is  a  POST  file  node  and  target  is  a  MAIL  file  node, 
the  edge  represents  the  distribution  of  records.  The  edge  means 
that  the  MAIL  file  may  receive  records  from  the  POST  file.  The 
MAIL  file  must  be  the  source  file  of  some  module  node( s ) .  This 
kind  of  am  edge  is  required  to  be  drawn  from  a  POST  file  to  each 
potential  MAIL  file  destination. 

iv)  if  the  source  and  target  are  both  ISAM  files,  the  edge  indicates 
that  the  source  is  an  "older"  version  of  am  ISAM  file  and  the 
target  is  a  "newer"  version  of  that  file.  The  "newer"  version  is 
available  only  after  the  production  and/or  consumption  of  the 
"older"  version  ham  been  completed .  This  kind  of  edge  allows  a 
user  to  indicate  the  sequential  access  to  an  ISAM  file.  Two  ISAM 
files  or  a  long  chauLn  of  progressively  newer  versions  of  an  ISAM 
file  may  be  connected  in  this  way. 

Depending  on  the  file  type  attribute,  there  axe  also  constraints 
on  the  number  of  edges  that  cam  be  associated  with  each  node.  This  is 
depicted  in  the  following  table. 
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PILE  PRODUCTION  AND  CONSUMPTION  RULES 


1 

* 

TYPE 

|  #  OF  PRODUCERS  ! 

#  OP  CONSUMERS  | 

REMARKS 

1 

1 

1 

1 

SAM 

!  n*o, 1  | 

m>=0  j 

n 

+  m  >  0 

-1 

i 

1 

1 

ISAM 

j  n>=0  j 

m>=0  ‘ 

n 

+  m  >  0 

1 

1 

1 

MAIL 

!  n>«l  ! 

m>=0  j 

n 

+  m  >  0 

1 

1 

POST 

!  1  I 

m>*l  J 

1 

1 

MODULE  PRODUCTION  AND 

CONSUMPTION  RULES 

1 

1 

TYPE 

!  #  PRODUCED  i 

*  CONSUMED  | 

REMARKS 

1 

1 

1 

1 

MDL, GRP 

!  n>=0  I 

m>=0  | 

n 

+  m  >  0 

1 

1 

1 

+■- 

MAN 

!  n=0, 1  | 

m=0, 1  j 

n 

+  m  >  0 

( 

I 

TABLE  1.  Pile  and  Module  Production  and  Consumption  Rules 

10.6  REQUIREMENTS  OP  CONNECTING  PILES 

The  user  of  CSL  must  select  the  type  of  a  file  which  connects 
modules  based  on  the  functional  requirements  of  the  configuration  as  a 
whole.  The  selection  of  the  file  type  must  be  reflected  both  in  the 
individual  producing  or  consuming  module  specifications  and  in  the 
configuration  specification.  The  functional  requirements  concern 
concurrency,  distributivity  and  sequentiality  in  operation  of  modules 
(section  10.6.1).  In  addition,  there  are  requirements  of 
compatibility  in  file  structures  as  specified  in  the  specifications  of 
the  producing  and  consuming  modules  (section  10.S.2). 

Pinally,  there  are  restrictions  on  modules  which  are  initiated 
manually  (section  10.6.3). 

10.6.1  CONCURRENCY,  DISTRIBUTIVITY  AND  SEQUENTIALITY 

The  requirement  and  choice  of  file  types  should  be  guided  by  the 
following: 

i)  If  a  copy  of  a  file  must  be  retained  then  only  SAM  or  ISAM  types 
files  may  be  used.  A  SAM  file  is  used  when  the  producer  module 
must  precede  entirely  the  consumer.  And  an  ISAM  file  may  be  used 
when  such  a  constraint  does  not  exist. 
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ii)  If  the  connected  modules  are  to  be  initiated  sequentially,  one 
preceeding  the  other  entirely,  the  relationship  among  them  may  be 
expressed  as  follows*. 

a)  The  path  between  the  predecessor  and  successor  modules 

includes  a  SAM  file,  or 

b)  The  path  between  the  predecessor  and  successor  modules 

includes  a  pair  of  same  named  (or  synonymous )  ISAM  files 
connected  by  an  edge  in  the  direction  from  the  predecessor  to 
the  successor. 

iii )  If  the  connected  modules  may  be  activated  concurrently  and/or 
distributively,  then  they  must  be  connected  by  either  MAIL  or 
POST  connected  to  MAIL. 

Modules  are  generally  scheduled  to  be  executed  as  early  as 
possible,  concurrently  or  otherwise,  subject  only  to  other  sequential 
dependencies  in  the  configuration  graph.  Thus,  the  user  of  CSL  must 
consider  whether  certain  modules  may  be  initiated  at  the  same  time  or 
one  preceding  another.  MAN  type  modules  must  be  concurrent  with  the 
modules  to  which  they  are  connected  via  files.  Requirements  of 
sequentiality  are  usually  imposed  by  the  outside  environment  ( schedule 
of  work  of  people,  etc.).  Otherwise,  it  i3  generally  more  efficient 
to  operate  modules  concurrently  and,  in  cases  that  do  not  involve 
other  considerations,  it  is  preferable  to  use  MAIL  files. 

Distributed  modules  cam  only  exchange  messages  through  MAIL  and 
POST  files.  Consequently,  every  SAM  or  ISAM  file  consumed  or  produced 
by  a  module  must  be  located  in  the  same  node(  computer )  in  a  network 
with  the  module.  Modules  exchanging  information  through  SAM  or  ISAM, 
if  resided  on  different  nodes  in  a  network,  will  signal  an  error. 

10.6.2  COMPATIBILITY  OF  CONNECTING  PILES 

The  definition  of  data  structures  of  a  connecting  file  must  be 
included  in  the  MODEL  specifications  of  all  its  producer  and  consumer 
modules.  These  data  structure  declarations  in  the  different  modules 
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may  vary  i  some  respects  but  otherwise  must  strictly  agree. 

i)  BEOOE  STRUCTURES :  Corresponding  record  structures  must  have  the 
same  .ength  and  their  respective  constituent  groups  and  fields 
must  ive  the  same  dimensionality,  range,  data  type,  length  and 
scale  Namely  the  trees  representing  respective  record 
art  rue  ires  in  different  module  specifications  must  be  the  same. 
Bowev  :,  the  respective  records,  groups  and  fields  may  be  named 
diffe  ■ntly. 

ii)  EXLE  mfCTURESi  The  order  of  different  record  structures  in  a 
conne  :ing  file  ( from  left  to  right  in  the  file  tree )  must  be  the 
same  t  all  the  specification  of  the  modules  connected  by  the 
file.  Also  the  total  numbers  of  records  with  respective  data 
struc  ires  must  be  the  same.  Note  that  the  nurter  of  records 
need  iot  be  constant.  The  number  of  records  may  also  be  denoted 
for  e  ;h  dimension  by  END-OP— PILE  marker  or  by  variables  (with 
DID  r  SIZE  prefix).  It  is  not  required  that  the  number  of 
dimen  _ona  of  respective  records  be  the  same,  but  their  total 
numbe  must  be  the  same.  The  DTO-OF-PILE  marker  must  not  be  used 
to  de  >te  the  size  of  a  vector  of  records  in  a  MAIL  file,  other 
means  such  as  a  constant  or  END  or  SIZE  prefixed  variables,  may 
be  us  1. 

iii)  VI ETC  ,  DIMENSIONS  QP  RECORD  STRUL'lilKES  8  To  achieve  concurrent 
opera  .on  of  modules  connected  by  MAIL  files  (or  POST  connected 
to  MA  ,),  the  producer  module  has  to  produce  one  record,  or  a 
group  if  records,  at  a  time  and  these  records  have  to  be  consumed 
also  ie,  or  a  group  of  them  at  a  time.  This  requirement 
corre  xsnds  in  the  MODEL  system  to  having  virtual  dimension  at 
the  h  heat  order,  and  possibly  immediate  lower  order,  record 
dimen  .ons.  Information  about  the  types  of  dimensions  for  a 
spec!  .cation  is  included  in  the  MODEL  reports.  It  is  the 
respc  ibility  of  the  CSL  user  to  verify  the  above  said 
requi  ments  to  be  satisfied. 


10.6.3  MANUAL  INITIATION  OP  MODULES 


The  modules  that  are  to  be  initiated  manually  must  be  prefixed  in 
a  CSL  specification  with  the  "+”  sign.  It  is  cannon  in  large  systems 
that  the  number  and  duration  of  operation  of  some  modules  is  not  known 
in  advance.  this  is  typical  in  modules  that  are  connected  to  a  MAN 
type  of  module,  i.e.  where  a  human  operator  of  a  terminal 
comminicates  with  a  module.  Such  a  module  is  then  initiated  by  the 
operator.  The  number  of  such  modules  and  when  they  are  initiated 
depends  on  the  number  and  schedule  of  work  of  the  terminal  operators. 
There  are  several  requirements  of  a  module  prefixed  by  ”4-"  as  follows. 

i)  SAM  files ;  The  module  may  produce  or  consume  SAM  files  provided 
that  they  axe  not  connected  to  other  modules. 

ii)  concurrent  operation:  The  module  must  operate  concurrently  with 
other  modules  as  follows: 

a)  it  may  produce  files  only  of  type  MAIL  (or  POST  connected  to 
MAIL)  or  ISAM  which  may  be  connected  to  other  modules 

b)  it  may  consume  files  only  of  type  POST  connected  to  MAIL  or 
ISAM  which  may  also  be  connected  with  other  modules. 


10.7  SYNONYM  STATEMENT 

A  synonym  statement  is  used  to  identify  the  equivalence  between 
logical  names.  Synonymous  names  correspond  to  a  single  physical 
entity. 


Synonymous  names  must  be  all  of  MODULE  or  all  of  PILE,  and  must 
have  the  same  or  complementary  attributes.  Synonymous  file  names  may 
I  be  prefixed  by  the  producing  or  consuming  module  name. 

The  synonym  relation  is  symmetric,  transitive  and  reflexive,  i.e. 
if  S:  A,B;  and  S:  B,C;  are  two  synonym  statements,  then  S:  B,A; , 
S:  B,C>  and  S:  A,Cj  are  implied.  Also  for  every  node  X  in  a 
configuration,  S:  X,X;  is  always  assumed. 
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10.8  OPERATING  THE  CONFIGURATOR 


10.8.1  INVOKING  THE  CONFIGURATOR 


To  activate  the  Configurator,  a  user  calls!  "8RO 
specification  name>".  This  executes  the  following  VMS 
procedure: 


•RCONF  <CSL 


3 ASS  ERMSGE.OAT  ERMSGE 
3 ASS  'PI' .CNF  SAPIN 
3 ASS  SYSOOT.DAT  SYSSOUTPOT 
3 ASS  SYSIN.DAT  SYS 3 INPOT 
3 RUN  CONF 
3 DEASS  ERMSGE 
3DEASS  SAPIN 
SDEASS  SYSSOUTPOT 
3DEASS  SYS 3 INPUT 


/*  Connect  the  ISAM  error  msg  file  */ 
/*  Connect  P1(CSL  specification)  */ 
/*  Connect  the  timing/trace  file  */ 
/*  Connect  the  parameter  file  */ 
/*  Activate  the  Configurator  */ 
/•  Disconnect  error  msg  file  */ 
/*  Disconnect  CSL  spec  file  */ 
/•  Disconnect  screen  output  */ 
/*  Disconnect  keyboard  input  */ 


10.8.2  I/O  FII£  NAMING  CONVENTIONS 


NAME  CONVENTION 


"namel"  .CNF 

SYSIN.DAT 

ERMSGE.OAT 

RPT.DAT 

SYSOOT.DAT 

CONFERR.DAT 
"namel" .COM 
"namel"  .PLI 
"nasiel-D.PEI 
"namei-.COM 


C0M4ENT 


K  file  containing  a  CSL 
specification  named  "nasml" 
Parameter  file 
Syntax  error  ISAM  file 
Report  file 

Configurator  timing  and 
debugging  message  file 
Error  message  file 
Main  JCL  program  file 
Mailbox  creation  program 
Mailbox  deletion  program 
Individual  JCL  program  file 


TABLE  2.  I/O  File  Name  Conventions  of  the  Configurator 


The  Configurator  generates  N+l  JCL  programs,  where  N  equals  to 
the  number  of  modules  in  a  configuration.  Each  individual  JCL  program 
is  named  after  the  corresponding  module  nasm  ( "nasmi"  in  the  above 
table)  in  the  configuration  eutd  the  main  JCL  program  is  named  after 
the  name  of  the  configuration. 

The  report  file  (RPT.DAT)  may  contain  up  to  seven  reports 
generated  by  the  Configurator  according  to  selected  options  (see 
section  11.3.5).  The  system  timing  and  debugging  message  file 


(SYSOUT.DAT)  contains  the  timing  of  each  processing  stage,  and  if 
debug  option  has  been  selected,  the  debugging  messages  from  the 
Configurator.  The  debugging  messages  are  provided  for  debugging  the 
Configurator. 


10.8.3  PARAMETERS  TO  THE  CONFIGURATOR 


The  Configurator  uses  a  parameter  file  (SYSIN.DAT)  which  is  used 
to  select  options  to  perform  or  not  perform  certain  functions  of  the 
Configurator. 

The  parameters  are  summarized  below. 


PARAMETER 


MEANING 


1.  NT/TRACE 

2.  NC/GENCODE 

3.  LST/NLST 

4.  St  /NGP 

5.  XFEF/HXREP 

6.  MSCC/NMSCC 

7.  GE/HGE 

8.  MFREF/NMFREF 

9.  JCLS/NJCLS 


— turn  off  /on  the  debugging  messages 
— turn  off/on  the  code  generation  switch 
— do/do  not  list  the  CSI»  specification 
— do/do  not  generate  the  configuration  graph(Gf) 
report 

— do/do  not  generate  the  CSL  cross  reference  report 
— do/do  not  generate  MSCCa  in  Gf 
— do/do  not  generate  the  extended  component 
graph ( Ge )  report 

— do/ao  not  generate  the  module-file  cross 
reference  report 

— do/do  not  list  the  JCL  and  PL/I  programs. 


TABU!  3.  Parameters  to  the  Configurator 


The  defaults  are  underlined.  The  parameters  can  be  positioned  in 


SYSIN.DAT  in  an  arbitrary  order  in  a  line  and  separated  by  a  blank  or 
any  other  delimiters.  For  example,  the  following  can  be  the  content 
in  a  SYSIN.DAT:  “XREF,KSCC,GE,GEJICOOE" . 


CHAPTER  11 


THE  CONFIGURATOR 


L\ 


I 


a 
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The  Configurator  is  in  fact  the  CSL  compiler .  it  accepts,  as 
input,  a  specification  in  CSL  and  produces  executable  PL/ I  programs 
for  setting  up  consunications  between  modules,  comnand  programs  for 
executing  the  configuration  and  documentation  of  the  configuration. 


11.1  STRUCTURE 

The  main  procedure  of  the  Configurator  is  described  in  section 

11.3. 

The  Configurator  processes  a  CSL  specification  through  the 
following  stages: 


Cl] 

[21 

C3] 

C41 

C5] 

C6] 

C7] 


Syntax  analysis  and  construction  of  the  configuration  graph 


Completeness  analysis 
Sequence  checking 
Scheduling 

MSCC  diameter  evaluation 
Code  generation 
Configuration  documentation 


(section  11.4) 

(section  11.5) 

( section  11.6) 

(section  11.7) 

( section  11.8) 

( section  11.9) 

( section  11.10)  • 


The  control  flow  of  the  Configuator  is  depicted  in  Figure  17. 
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11.2  PRODUCTS 


The  Configurator  produces  a  number  of  outputs.  They  consist  of  a 
set  of  configuration  programs  and  documentation .  The  set  of  programs 
is  in  two  languages:  JCL  and  PL/I .  The  reports  and  programs  are 
listed  in  the  Documentation  and  Code  Generation  columns  at  right  of 
Figure  17.  The  JCL  programs  can  be  categorized  into  two  groups: 


i)  A  main  JCL  program  -  which  creates  mailboxes  and  submits 
individual  JCL  programs  into  an  available  operating  system 
(currently  VMS  on  VAX-750)  and  synchronizes  the  termination  of 
the  JCL  program  with  the  terminations  of  all  the  modules  in  the 
configuration . 

ii)  Individual  JCL  programs  -  one  for  each  module  node  in  the 


Individual  JCL  programs  -  one  for  each  module  node  in  the 
configuration  graph.  Each  individual  JCL  program  synchronizes 
its  sequential  predecessor^  s ) ,  connects  the  logical  file  names  to 
appropriate  physical  files  and  activates  a  module.  When  the 
module  terminates,  the  JCL  program  disconnects  the  files. 


The  PL/I  programs: 

i)  Mailbox  creation  program 

ii)  Mailbox  deletion  program 

The  mailbox  creation  program  is  activated  by  the  main  JCL  program 
to  create  necessary  mailboxes  before  the  system  execution.  Each 
individual  module  also  creates  mailbox(es)  for  its  own  needs  and 
deletes  the  mailbox< as)  at  its  completion.  This  allows  a  module  to  be 
initiated  repeatedly  without  re-activating  the  mailbox  creation 
program  in  the  main  JCL  program. 

0 

The  mailbox  deletion  program  is  useful  in  the  debugging  of  the 
system.  A  test  process( module )  may  fail  to  complete  processing  and 
the  failure  may  occur  before  the  mailbox  deletion  part  in  the  program. 
The  mailbox(  es )  associated  with  the  module  may  then  contain  some 
unprocessed  messages  which  may  effect  the  next  run.  The  mailbox 
deletion  program  can  be  used  to  clear  up  the  mailboxes.  Therefore  it 
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must  be  activated  manual ly  in  cue  of  process  failure. 

Each  run  of  the  Configurator  generates  up  to  seven  reports.  The 
user  can  select  desired  reports  (see  Table  3). 


11.3  THE  MAIN  CONFIGURATOR  PROGRAM:  CONP 

The  main  configurator  program  calls  the  procedures  for  respective 
phases  of  the  Configurator.  The  calling  sequence  of  different 
processing  stages  are  shown  in  Figure  17.  me  calling  sequence  of 
processing  stages  is  from  left  to  right  in  the  figure. 


11.4  SYNTAX  ANALYSIS  AND  CONFIGURATION  GRAPH  CONSTRUCTION  (PROCEDURE 
NAME:  SAP) 

11.4.1  THE  SYNTAX  ANALYZER 

The  syntax  of  CSL  is  described  in  the  Extended  Backus-Naur  Form 
With  Subroutine  Calls(  EBNF/WSC ) .  The  EBNF  part  defines  the  syntax  of 
CSL,  and  subroutine  calls  incorporated  into  it  facilitate  semantic 
checking  and  configuration  graph  construction.  The  following  is  a 
brief  presentation  of  the  syntax  analyzer  of  CSL. 

A  recursive  descendent  parser  generator  is  employed  in  processing 
of  the  EBNF/WSC  description.  The  parser  generator  reads  the  EBNF/WSC 
description  of  CSL  and  generates  a  Syntax  Analysis  Program( SAP ) .  The 
SAP  calls  the  embedded  semantic  subroutines  while  parsing  CSL 
statements.  Semantic  checking,  error  reporting  and  graph  construction 
are  performed  by  those  routines.  This  scheme  has  allowed  easy 
modification  of  the  syntax  and/or  semantics  of  the  earlier  versions  of 
CSL. 


The  semantic  routines  can  be  classified  into  two  different 


categories 
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i)  Semantic  checking  and  graph  construction 

These  routines  recognize  particular  symbols,  create  new 
nodes  and  construct  a  configuration  graph  while  SAP  is  parsing 
the  CSL  statements.  The  syntactical  restrictions  that  are  not 
expressed  in  EBNF  sure  checked  by  particular  routines .  For 
example,  if  aui  identifier  M  is  used  as  the  name  for  a  MODULE  node 
and  MF:  M"  appears  in  the  CSL  specification,  the  routine  CK_NAME 
will  report  this  as  an  error( see  next  section ) . 

ii)  Error  message  routines 

These  routines  perform  syntax  error  reporting.  They  are 
referred  to  in  EBNF/MSC  as  /E(i)/,  where  i  denotes  an  integer 
representing  an  error  code.  They  are  always  placed  before  a 
routine  that  recognizes  a  keyword  or  a  delimiter.  SAP  stacks 
error  codes  ( from  the  corresponding  reference  /E( i )/ )  whenever  it 
calls  the  routine.  When  SAP  fails  to  recognize  a  certain  symbol, 
the  code  will  be  on  the  top  of  the  stack.  SAP  then  pops  the 
stack  and  calls  a  routine  SPAIL  which  prints  a  predefined  error 
message  indexed  by  that  code.  The  list  of  all  the  warning  and 
error  messages  produced  in  syntax  analysis  can  be  found  in 
Appendix  C. 

The  same  lexical  analyzer  (LEX)  is  used  in  the  MODEL  processor. 
LEX  is  called  by  various  routines  from  SAP. 

In  the  EBNP/wsc  description,  the  semantic  routine  calls  are 
enclosed  in  "/"  signs.  The  following  is  the  complete  EBNF  description 
of  CSL. 

<CONF_PROG>  :i-  < READER >  [< DECLARATIONS >/CLRERRF/]* 

/STMT_FL/  <CONF_PROG> 

< HEADER >  : CONFIGURATION >  /E( 10  )/  <NAME>  /CONFNM/ 

C  DIAM  :  <INTEGER>  ]  /E( 1 )/  ;  /LINENUM/ 

< DECLARATIONS >  : < SYNONYM >  /E( 1 )/  ?  /LINENUM/ 

|  <  DECLARATION >  /E( 1 )/  ;  /LINENUM/  /CLRALL/ 

|  0#_END#S  /ENDINP/ 


(to  be  continued) 


< DECLARATION >  :  •.«  <M>  /E(4>/  :  /E(  2  )/  <M_NAMES> 

[  < ARROW>  /E( 11 )/  <M_F)  /STMP/]* 

|  <F>  /E( 4)/  :  /E( 2 )/  <F_NAMES) 

[  < ARROW)  /E( 11 )/  <M_F>  /STMF/1* 

«K_F>  ss«  <M>  /E( 4 )/  :  /E(  2  )/  <M_NAMES> 

|  «P>  /E(  4)/  s  /E(2)/  <F_NAMES) 

< ARROW)  : s-  /ARROW/ 

<M>  t /RECM/ 

<F>  : J-  /RECF/ 

<KJNAMES>  j:»  <H_NAME)  /ADONAME/  f ,  <M_NAME>  /ADONAME/]* 

<1  .NAMES)  ss»  <F_NAME)  /ADONAME/  f , <F_NAME>  /ADDNAME/]* 

<K_NAME>  C  +  /GETPM/3  [<LOC)]  [<DEVICE>]  [ <DIRECTORY> ]  /E(5)/ 

<NAME)  /STLNAME/ 

C»/E( 5 )/<NAME>  /STPNAME/ 
r  <SUFIX>  [<V5N>]  ]] 

f  (  /E( 12 )/  <KORG>:  /E( 6 )/  <M_TYP>  /STORG/  )]  <CX_NAME> 
<F_NAME>  :s-  [<LOC>]  C<DEVTCE)]  C < DIRECTORY > ]  /E( 5  )/ 

<NAME>  /STLNAME/  [ •  < NAME >  /MDFLNM/  ] 
r-/E( 5)/<NAME>  /STPNAME/ 

<SOFIX>  [<VSN>]  ]] 

'  (  /E( 12 )/  <KORG>:  /E( 6 )/  <F_ORG>  /STORG/  f  )] 

RSs  /E( 7 )/  < INTEGER)  /STSIZE/  )]]  <CK_NAME» 

<KDRG>  : ORG  |  TYPE  |  TYP 

<LOC>  : /GETLOC/ 

< DEVICE)  ; !«  /GETOEV/ 

< DIRECTORY) : /GETDIR/ 

<SUFIX>  : :■  .  /GETTYP/ 

<VSN>  .  /E( 8  )/  < INTEGER)  /STVSN/ 

<CX_NAME>  : s-  /CKNAME/ 

<F_ORG>  : SEQL  j  ISAM  |  MAIL  j  POST 

<H_TYP>  : MAN  |  GRP  |  MDL 

< SYNONYM)  ss-S  s  /E<9)/  <LJIAME>/E( 10 )/,/£( 9 )/<L_NAME> 

C»  /e<9)/  <ljwme>i*  /WGSYN/ 

<L_NAME>  <MAME>  /STSNAME/  [ .  <NAME>  /MDFINM2/  ] 

<NAME  : /NAMEREC/ 

<  INTEGER)  /INTREC/ 

FIGURE  18.  EBNF/WSC  Description  of  CSL 


The  following  table  contains  all  the  semantic  routines  and  their 
functions  in  the  above  EBNF/WSC  description. 


NAME  FUNCTION 

CLRALL  Clear  global  and  local  graph  pointers. 

ARROW  Recognizes  the  symbol  "■>  " . 

RECM  Recognizes  "M"  as  the  prefix  of  node(s). 

RECF  Recognizes  ”P"  as  the  prefix  of  node(s). 

ADONAME  Adds  the  currently  scanned  nans  into  the  local  graph 

STLNAME  Stores  a  logical  name. 

IPFIMM  Modifies  the  stored  logical  name  to  be  prefixed. 

STPNAME  Stores  a  physical  name. 

STORG  Stores  organization  of  a  file  node. 

STSIZE  Stores  record  size. 

GETPM  stores  the  sign  of  a  node. 

GETLOC  Recognizes  and  stores  the  network  address  of  a  node. 

GETDEV  Recognizes  and  stores  a  device  description. 

GETDIR  Recognizes  and  stores  a  directory  description. 

GETTYP  Gets  the  suffix  of  a  physical  name. 

(to  be  continued) 


STVSN  Recognizes  and  stores  a  version  number. 

CXNAME  Checks  the  currently  scanned  nodes 's  attribute. 

MGSYN  Merges  synonymous  names  into  one  node. 

STSHAME  Stores  the  current  synonymous  name  in  a  list. 

MDFUAME2  Modifies  the  node  name  in  a  synonym  list  to  be 

_  prefixed. 

NAMEREC  Recognizes  an  identifier. 

INTREC  Recognizes  an  integer. 

TABLE  4.  Semantic  Routines  For  CSL 


11.4.2  DEFINITION  OF  A  CONFIGURATION  GRAPH 


Let  M  and  F  denote  two  non-empty  disjoint  sets  of  elements.  We 
interpret  elements  of  the  set  M  as  modules,  and  those  in  the  set  F  as 
files. 

DEFINITION  1. 


A  DIRECT  CONFIGURATION  GRAPH  is  a  graph  Gf '»( Vf * ,Ef ' ),  with  a  set 
of  nodes:  Vf*-M  U  F,  and  a  set  of  edges  Vf*  e  (M  x  P)  U  (F  x 


(F  0  M)). 

For  an  edge  e-<vl,  v2>  e  Ef  ’ ,  we  will  assume  the  following 


interpretation : 

i)  Ife  e  Ef’  c(MxF)  then  it  represents  a  production 
relationship,  i.e.  the  file  v2  is  produced  by  module  vl; 

ii)  If  e  €  Ef'  c  (F  x  M)  then  it  represents  a  consumption 
relationship,  i.e.  the  file  vl  is  consumed  by  module  v2; 

iii)  ife  €Ef'  C(FxF)  then  the  edge  represents  the  casuality 
relationship  between  file  vl  and  v2  as  described  in  section  10.3. 

□ 

OEflHITIQM  2. 


A  pair  of  nodes  v  and  w  in  a  configuration  is  said  to  be  DIRECTLY 
EQUIVALENT,  denoted  by  v  <  «>  w,  if  and  only  if: 


i)  v-w;  or 

ii)  there  is  such  a  SYNONYM  statement  S:(ul,u2, . . .uk)  that  for  some 
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i,  j,  v-ui,  w»uj.  □ 

We  denote  by  <*  the  transitive  closure  of  <  «>.  We  will  say  that 
v  and  w  are  SYNONYMOUSLY  EQUIVALENT  if  and  only  if  v  “  w. 

Clearly,  *  is  an  equivalence  relation,  defining  the  partition  of 

Vf’  into  equivalence  classes  Vf'/  ».  It  can  also  be  extended  to 

equivalence  among  edges  in  Ef*  by  defining: 

<vl,v2>  “  <v3, v4>  iff  vl  «  v3  and  v2  «  v4. 

Hence  the  projection  P:  Vf'  ->  vf'/  “  transforms  Ef*  into  Ef'/  * 

and  also  the  DIRECT  CONFIGURATION  GRAPH  Gf'  into  the  CONFIGURATION 
GRAPH  Gf  defined  as  follows. 

DEFINITION  3. 

A  gqnptgurattom  GRAPH  is  a  graph  Gf=(Vf  ,Ef )  such  that  Vf=Vf '/  « 
and  Ef-Ef/  «.  a 

We  will  denote  by  Nf  the  number  of  nodes  in  Gf  and  by  Ef  the 
number  of  edges. 

11.4.3  CONSTRUCTION  OF  THE  CONFIGURATION  GRAPH 

The  construction  of  the  configuration  graph  is  performed  during 
syntax  analysis  stage. 

To  illustrate  the  composition  process,  we  select  the  EBNF 
productions  of  the  path  statement  and  a  sample  CSL  specification 
containing  two  path  statements: 

M:  MX  ->  P:  TEST1; 

M:  Ml  ->  F:  TEST1  ->  M:  M2  ->  F:  TEST2,  TESTS; 

we  first  show  below  a  segment  of  the  SAP  program  corresponding  to  the 
productions  of  the  path  statement.  The  graph  construction  mechanism 
is  demonstrated  through  description  of  functions  of  various 


sub- routines  in  the  SAP  program. 

The  following  segment  is  a  simplified  EBNF  description  of  the 
path  statement. 


<PATHSTMT> 


< ARROW  > 

<H_P> 

<M> 

<P> 

<MF_NAMES> 


ss-  <M_F>/B(4)/  s  /E( 2 )/  <MP_NAMES>  [  < ARROW > 
<H_P>/E(4)/  s  /E( 2 )/  <MF_NAMES>  /STOP/  ]* 
/E( 1 )/ ; /CLRALL/ 

/ARROW/ 

<M>  |  <P> 

:»  /RE CM/ 

■x  /RE CP / 

:*  <MP_NAME>  /ADDNAME/  [,<MP_NAME>  /ADDNAME/]* 


FIGURE  19.  Segment  EBNP/WSC  of  the  Path  Statement 


Pollowing  is  the  segment  SAP  program  for  PATHSTMT: 

PATHSTMT:  PROCEDURE  RETURNS( BIT( 1 )  ) ; 

CALL  SHARK; 

IP  H_F( )  THEN  DO; 

CALL  E(4);  CALL  LEX; 

IP  IEXBUPP  =-  1  :  '  THEN  DO; 

CALL  LEXENAB;  CALL  SPOPP; 

IF  MF_NAMES( )  THEN  DO; 

SSYS_002:  ; 

IF  ARROW( )  THEN  DO; 

IP  M_P( )  THEN  DO; 

CALL  E(4);  CALL  I EX; 

IP  IEXBUPP  -  '  :  •  THEN  DO; 

CALL  LEXENAB;  CALL  SPOPP;  CALL  E(2); 

IP  MP_NAMES(  )  THEN  DO; 

CALL  STMF; 

00  TO  SSYS_002 ; 

END; 

ELSE  DO;  CALL  SSUCCES;  RETURN( *  1 • B ) ;  END; 
END;  ELSE  DO;  CALL  SPAIL;  RETURN( *  1 ' B ) ;  END; 
END;  ELSE  DO;  CALL  SSUCCES;  RETURN( • 1 ’ B ) ;  END; 
END ; ELSE; 

CALL  E( 1 );  CALL  LEX; 

IP  LEXBUPF  -  ’ ; ■  THEN  DO; 

CALL  LEXENAB;  CALL  SPOPP;  CALL  CLRALL; 

CALL  SSUCCES;  RETURN(  ' 1 1 B ) ; 

END;  ELSE  DO;  CALL  SPAIL;  RETURN< ’ 1 ' B ) ;  END; 

END;  ELSE  DO;  CALL  SSUCCES;  RETURN( ' 1 ' B > ;  END; 

END;  ELSE  DO;  CALL  SPAIL;  RETURN( ' 1 ' B ) ;  END; 

END;  ELSE  DO;  CALL  SPAIL;  RETURN( ' O ' B ) ;  END; 

END  PATHSTMT; 

M_P:  PROCEDURE  RETURNS(BIT(1)); 

CALL  SHARK; 

IP  RECM(  ) 

THEN  DO; 

CALL  SPOPP;  CALL  SSUCCES;  RETURN( 'l’B); 

END;  ELSE  DO; 

IP  RECF(  ) 

THEN  DO; 

CALL  SPOPP;  CALL  SSUCCES;  RETORN( 'l’B); 

END;  ELSE  DO;  CALL  SPAIL;  RETURN( ' O ' B ) ;  END; 

END; 

END  H_P; 


(to  be  continued) 


MF_NAMES :  PROCEDURE  RETUFNS( BIT( 1 ) ) ; 

CALL  $MARK; 

IP  MP_NAME(  ) 

THEN  DO; 

CALL  ADDNAME; 

SSYS_003 :  ; 

CALL  LEX; 

IF  UEXBUFF  -  1 , '  THEN  DO; 

CALL  LEXENAB; 

IF  MF_NAME(  )  THEN  DO; 

CALL  ADDNAME; 

GO  TO  $SYS_003; 

END;  ELSE  DO;  CALL  SSUCCES;  RETUFN( ' I ■ B ) ;  END; 
END;ELSE; 

CALL  SSUCCES ;  RETURN( *  1  * B )  ; 

END;  ELSE  DO;  CALL  SFAIL;  RETURN( • 0  * B  ) ;  END; 

END  MF_NAMES; 

FIGURE  20.  Segment  SAP  of  the  Path  Statement 


E( 1 ) ,  E( 2 )  and  E(4)  are  the  error  message  routines.  They  report 
missing  • ; * ,  unrecognized  node  name(  lexical  analysis  error )  and 
missing  1  1  respectively. 


SMARK  is  a  routine  that  pushes  a  string  of  blank  characters  into 
the  error  stack.  Routine  SSUCCESS  empties  the  error  code  stack  after 
parsing  a  production  successfully.  Routine  SFAIL  reports  syntax 
errors.  SPOPP  is  a  routine  that  pops  an  error  code  off  the  error 
stack  after  an  error  code  related  non-terminal  has  been  parsed 
successfully.  Por  instance,  if  the  call  RECM  is  successfully  parsed, 
SPOPF  will  be  called(see  above). 

LEX  is  the  lexical  analyzer.  It  produces  a  globally  accessible 
buffer,  LEXBUFP,  as  output.  The  buffer  contains  a  recognized  symbol. 
LEXENAB  is  a  routine  that  recognizes  the  symbol  next  to  the  currently 
recognized  one.  It  is  used  when  user  programmed  "look  ahead"  is 
needed.  In  fact,  it  is  a  lexical  analyzer  ( LEX)  in  the  form  of  a 
function. 

The  graph  construction  is  carried  out  by  i)  building  a  local 
graph  for  each  CSL  statement,  and  ii)  concatenating  the  local  graph 
with  a  global  graph.  Initially,  the  global  and  local  graphs  are  both 
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Being  a  recursive  descendent  parser,  SAP  scans  generally  only  the 
current  symbol  and  is  not  able  to  look  ahead.  Thus  the  semantic 
routines  have  to  store  information  that  they  need  to  keep  track  of  the 
previously  parsed  symbols. 

A  typical  example  of  a  specification  in  EBNP  is  the  design  of 
routines  RECK  and  recp. 

Routines  /RECM/  and  /RECF/  perform  the  following  tasks: 

i)  recognizing  the  key  words  P  or  M, 

ii)  comparing  the  keywords  in  the  previous  and  current  nodes  and 
reporting  an  error  if  a  M->M  edge  is  found  in  the  specification, 
and 

iii)  storing  the  currently  scanned  key  word  for  the  next  comparison. 

Non-terminal  HP_NAME  contains  a  routine  (not  shown  above)  that 
searches  a  symbol  table  for  node  type.  If  the  node  name  has  been 
found  in  the  table,  the  corresponding  node  in  the  graph  is  located  and 
the  current  keyword  (M  or  P)  is  checked  against  the  information  stored 
in  the  table.  Error  message  will  be  issued  if  a  difference  is  found. 
Otherwise  a  new  node  with  a  specified  keyword  is  created. 

The  function  of  routine  ADDNAME  is  to  create  a  list  of  MODULE  or 
PILE  names  by  concatenating  the  currently  processed  node  to  the  list. 
The  header  of  the  list  is  globally  accessible. 

Routine  STMP  takes,  as  input,  two  lists  of  names  constructed  from 
the  two  sides  of  a  symbol.  It  then  creates  an  edge  from  each 

node  on  the  left-hand-side  of  the  "->"  symbol  to  each  one  on  the 
right-hand-side . 

Routine  CLRALL  simply  concatenates  the  local  graph  with  the 
growing  global  graph. 

Now  suppose  that  we  have  the  two  CSL  path  statements  shown 
before.  Initially  the  global  and  local  graphs  are  both  null.  When 
SAP  comes  to  call  PATHSTMT,  it  then  calls  routine  H_F.  Since  the 


current  symbol  is  "M" ,  routine  H_P  returns  "true"  to  PATHSTMT. 
PATHSTWT  then  calls  E(4)  Which  stacks  error  code  "4"  onto  the  stack. 
E( 4 )  produces  a  message  reporting  missing  in  a  CSL  specification. 
The  SAP  then  calls  I£X  to  get  suiother  symbol/  and  checks  if  it  is 
If  ":"  is  the  current  scanned  symbol,  SAP  calls  LEXENAB  to  pop  the 
code  "4"  off  the  stack;  otherwise  it  calls  9FAIL  to  report  the 
missing  " : "  error. 

In  the  chosen  example,  ":"  does  appear,  so  MF_KAMES  is  the  next 
routine  to  be  called  in  SAP. 

Inside  MF_NAMES,  routine  ADONAME  is  called  to  create  a  single 
node  list.  Since  ","  does  not  appear  on  the  left-hand-side  of  the 
"->"  symbol,  routine  MP_NAMES  simply  calls  9SUCCES  and  returns  to  SAP. 

The  SAP  then  calls  ARROW  which  is  a  routine  for  recognizing  the 
"->"  symbol.  in  the  chosen  CSL  example,  ARROW  must  succeed.  The 
right-hand-side  of  the  "->"  symbol  is  then  processed  in  the  same  way 
until  the  SAP  reaches  STOP  which  creates  a  local  graph  from  both  sides 
of  the  "->"  symbol.  The  snap-shot  picture  at  this  moment  is  shown 
below. 

Global  Graph  Local  Graph 

(null)  4- — Hh  ♦  4—— F — 4 

I  MX  | - >  jTESTl  j 

4 —  4  4 —  -4 

Similar  to  processing  the  is  checked.  Finally  the  SAP 

reaches  clrall  which  concatenates  the  local  graph  to  the  global  graph 
and  sets  the  local  graph  to  be  null. 

During  parsing  the  second  line,  TEST1  is  identified  as  existing, 
so  the  local  process  starts  with  this  node  taken  from  the  global 
graph. 
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Before  reaching  routine  CLRALL,  we  have  the  following  situation: 


Global  graph 


Local  graph 


(MX) 

I 

v 

4-M — f  ■*— M — 4  -t P 4  4 — M — 4  4-— F — ► 

|  MX  | — >( TEST1 )  |  Ml  |-> |TESTl|-> |  M2  |-> |TEST2| 

4 - H  4 - f  >  -  t  4 - f  4  I 

I 

|  +— P 4 

O - > '.TESTS! 

4  - ♦ 


The  graphs  after  the  completion  of  parsing  line  2  are: 
Global  Graph  Local  Graph 


+— M — 4 

|  NX  j  (null) 

♦  -4 

I 

v 

4— m — 4  +— p — »■  4— m — f  »■  p  » 

|  Ml  !-> jTESTl | — > j  M2  |— > |TEST2j 
4 - 4  4  -4  4-  ■■  4  4— —4 

O  > | TEST3  j 

4- - 4 


The  mechanism  used  to  process  the  SYNONYM  statements  is  similar. 
It  locates  the  nodes  specified  in  a  synonym  statement ,  takes  them  frcm 
the  global  graph,  and  attaches  than  to  the  last  node  (still  in  the 
global  graph)  in  the  statement. 


11.4.3.1  DATA  STRUCTURES  USED  IN  THE  GRAPH  CONSTRUCTION 

The  data  structures  used  in  graph  construction  is  shown  as 
follows . 


DCL  1  NODE  BASED( NFTR), 

2  TYPE  CHAR(1), 

2  DFNUMBER  FIXED  BIN,  /•  FOR  MSCC  FINDING  */ 

2  LOWLINX  FIXED  BIN, 

2  STATUS  CHAR(1),  /*  4  */ 

2  M_M_LRS  PTR,  /*  POINTS  TO  STMTNO  LIST  */ 

2  SYNHEADER  PTR,  /•  TO  THE  HEAD  OF  SYNONYM  LIST  V 
2  NAME  CHAR(  10 ), 


(to  be  continued) 


PNAME  CHAR<  10  ), 

LOC  CHAR(  10 ), 
DEVICE  CHAR(  10), 
DIRECTORY  CHAR(  20), 


SUPIX 
VERSION 
ORG 

REC.SIZE 

SYN.LIS 

PRE.LIST 

SOC_LIST 

HI 

NEW 

NECT 


CHAR(  3  ), 
FIXED  BIN 
CHAR(4), 
FIXED  BIN 
PTR, 

PTR, 

PTR, 
BIT(l), 
BIT(l), 
PTR;  / 


/*  POINTS  TO  NEXT  SYNONYMOUS  NODE 
/*  POINTS  TO  A  L1C  LIST  */ 

/*  POINTS  TO  A  LK  LIST  */ 

/*  FOR  PREFIXED  NAMES  */ 

/*  FOR  TRAVERSING  */ 

*  POINTS  TO  NEXT  NODE  IN  SYMBOL  TABLE 


V 


V 


DCL  1  UC.LIST  BASED(  LK.PTR ) , 

2  CLAIMED.ORG  CHAR( 4 ) ,  /*  UNUSED  */ 

2  STMT.NO  FIXED  BIN,/*  USED  TO  PRINT  X-REFERENCE  REPORT  */ 
2  PT  PTR,  /*  POINTS  TO  A  F  OR  A  M  IN  NODE  */ 

2  NEXT  PTR;  /*  POINTS  TO  THE  NEXT  LX  STRUCTURE  / 


GC  is  constructed  through  fields  MPRE_LISTM,  "SUCJLIST", 
"SYN.LIS"  and  "SYNJHEAD" .  Field  -SYN.HEAD"  points  to  the  head  of  a 
group  of  synonymous  nodes.  Every  group  of  synonymous  names  is 
connected  through  field  "SYN.LIS"  which  points  to  a  next  synonymous 
NODE  structure. 

Also  note  that  all  the  modules  and  files  in  a  configuration  are 
stored  in  two  alphabetically  sorted  linked  lists  through  the  pointer 
NEXT  in  structure  NODE.  One  such  list  consists  of  all  the  (unique) 
module  names  and  the  other  all  the  (unique)  file  names.  The  two  lists 
an  pointed  by  two  global  pointers  H_HD  and  P_HD  respectively. 


11.5  COMPLETENESS  ANALYSIS  (PROCEDURE  NAME:  CMP ANA) 

After  the  configuration  graph  construction,  a  completeness 
analysis  is  performed. 

* 

DETIWITIOM  4. 

A  configuration  graph  Gf  is  said  to  be  complete  if  and  only  if 


i)  no  node  is  isolated,  and 

ii)  each  MAIL  or  POST  typed  FILE  node  in  Vf  has  at  least  one  producer 
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and  consumer .  □ 

If  a  PILE  node  has  no  producers  and  consumers,  the  file  does  not 
participate  in  the  system  and  we  conclude  that  the  CSX*  specification 
is  incomplete.  If  a  MODULE  node  does  not  produce  and  consume  any 
files,  the  module  does  not  conasunicate  with  anything  and  is  not  part 
of  the  system,  we  also  conclude  that  the  system  is  incomplete. 

The  MAIL  and  POST  files  are  supposed  to  conmunicate  among 
modules.  Lack  of  either  a  producer  or  a  consumer  indicates  an 
incomplete  definition  of  the  system. 

The  analysis  is  a  simple  one-pass  scan  through  all  nodes  counting 
the  number  of  predecessors  and  successors  of  each  node .  Error 
messages  are  issued  if  the  Gf  is  found  to  be  incomplete. 

Other  checks,  such  as  on  "+"  modules  and  the  checks  on 
distributivity,  according  to  the  rules  stated  in  section  10.6.1,  sure 
also  performed  in  the  same  .procedure. 

11.6  SEQUENCE  CHECKING  (PROCEDURE  NAME:  SEQCK) 

11.6.1  PRELIMINARIES 

11.6.1.1  REQUIREMENT 

A  dataflow  analysis  approach  is  employed  to  check  the  execution 
sequence  of  a  configuration  to  check  for  conflicts  in  scheduling  of 
nodes. 

The  limited  information  provided  in  a  CSL  specification,  is  due 
to  the  assumption  that  each  module  is  ATOMIC. 

DETIMITIflM  5. 

An  ATOMIC  module  is  a  module  which  acquires  all  of  its  input 
files  at  beginning  of  its  execution  and  releases  all  of  its  output 


files  at  the  end  of  its  execution.  □ 


The  user  must  assume  that  all  the  module  nodes  in  the 
configuration  are  atomic .  in  many  cases  this  may  be  an  overly 
conservative  assumption.  In  particular  this  becomes  apparent  in  the 
case  of  GRP  nodes  as  illustrated  below.  Further,  the  use  of 
non-atomic  node  may  cause  loss  of  ability  to  conduct  some  checks  of 
correctness  of  a  configuration  and  also  loss  of  same  efficiency  in  its 
scheduling.  The  alternative  for  the  user  is  to  decompose  non-atomic 
modules  into  atomic  ones. 

For  instance,  if 

F:  FI  (TYPtMAIL)  -»  M:  MG  (TYPsGRP)  ->  Fs  FI; 

The  GRP  type  module  MG  may  have  two  different  sub-configurations 
each  containing  modules  MG1  and  MG2.  They,  however,  lead  to  totally 
different  configuration  graphs.  Note  that  what  appears  as  a  cycle  in 
the  above  statement  is  in  fact  not  a  cycle  in  Figure  21(a),  while 
there  is  a  cycle  containing  SMI  file  in  Figure  21(b)  which  is  not 
detectable  from  the  above  statement . 
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(a)  (b) 

FIGURE  21.  Two  possible  sub-configurations  of  a  GRP  module 


A  module  producing  only  ISAM  file(s)  does  not  impose  any 
execution  sequence  constraints,  thus  is  not  required  to  be  atomic. 


11.6.1.2  TEMPORAL  RELATIONS 

First,  we  define  temporal  relations  that  can  be  derived  from  a 
configuration  specification . 

In  any  timing  of  execution  of  a  system  described  by  the  given 
configuration,  each  module  Mi  is  represented  by  a  pair  of  time  points 
<Mis,Mie>,  standing  for  starting  and  ending  times  of  its  execution, 
respectively.  Values  of  such  starting  and  ending  times  are  highly 
inter-dependent  due  to  existence  of  certain  temporal  relation  between 
execution  times  of  modules.  Por  our  purpose  it  is  sufficient  to 
consider  the  following  three  temporal  relations. 

DEFINITION  6. 

Por  any  given  pair  of  time  intervals:  Ml><Mls,Mle>  and 

M2a><M2s,M2e>  we  say  that: 


Ml  »>  M2,  iff  Mle  <  M2s 

Ml  ->  M2,  iff  M2S  <  MIS  6  M2e  >  Mle 

Ml  | |  M2,  iff  MIS  -  M2 3  £  Mle  -  M2e 

We  refer  to  the  temporal  relation  "»>"  as  a  sequential  one,  to 
"-> "  as  a  mail  relation,  and  to  "II"  as  a  one.  By  " and 

we  denote  inverse  of  sequential  relation  and  mail  relation 
respectively.  Following  is  a  transitivity  table  for  the  defined 
temporal  relations: 
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Table  S.  Transitivity  table  of  relation  r  holding  between  Ml  and  M3 
assuming  that  Ml  rl  M2  and  M2  r2  M3  hold. 


For  example,  if  (Ml  ->  M2)  and  (M2  ||  M3)  hold,  then  we  can 

easily  show  that  Ml  ■>  M3  as  follows: 


(M2s  >  Mle)  from  definition  of  *> 

( M2  a  ■  M3  3 )  from  definition  of  ! 

so  (M3s  >  Mle),  hence  M3  ■>  Ml.  □ 

Other  entries  in  the  transitivity  table  can  be  proved  similarly. 


Sequential  relation  holds  between  modules  which  have  to  be 
executed  one  after  another.  This  relation  exists  between  the  producer 
and  consumer  of  a  SAM  file  or  a  sequentially  accessed  ISAM  file.  A 
mail  relation  exists  between  a  producer  and  a  consumer  module  of 
messages  through  a  mail  or  post  file.  It  indicates  that  the  consumer 
may  start  and  before  the  producer  and  finish  after  the  producer. 
Parallel  relation  exists  between  modules  exchanging  messages.  Note 
that  M1-»M?  and  M2->M1  implies  Ml||M2. 


There  are  five  basic  connections  in  a  configuration  graph  (Gf). 
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Where  < . >  means  that  the  edges  can  be  in  either  or 
both  directions. 
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implies  Ml  ->  M2 
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To  compute  the  temporal  relations  among  all  the  module  nodes  in  a 


configuration,  we  do  the  following. 


Initially  we  derive  all  the  temporal  relations  assumed  by  the 


basic  connections  stated  above . 


Note  that  the  derivation 


includes  the  case  when  a  module  is  defined  as  manually  initiated 
(i.e.  prefixed  by 

Additionally,  we  assume  that  for  every  module  Mi,  Mi|  |Mi. 

II.  Next,  all  consequences  of  constraints  imposed  in  I  are  computed. 
Note  that  whenever  we  find  Mi->Mj  and  Mj->Mi,  we  derive  Mil  |Mj . 

The  parallel  relation  is  an  equivalence .  Clearly  it  is 
transitive,  sy metric  and  reflexive.  Thus  we  can  consider  am  image  of 
the  sequential  and  mail  relation  under  the  projection  mapping  a  set  of 
modules  into  a  set  of  module  equivalence  classes  under  | | .  It  is  easy 
to  see  that  the  equivalence  classes  are  groups  of  modules  enclosed  in 


MSCCs  connected  only  by  post  and  mail  files.  He  will  later  refer  to 
the  equivalence  class  containing  module  Mi  as  to  the  component  of  Mi. 

The  derivation  of  temporal  relations  is  used  to  perform  sequence 
and  consistency  checking. 


11.6.2  SEQUENCING  ANALYSIS 

The  aim  of  the  analysis  is  to  locate  modules  that  have  an 


inconsistent  activation  sequence  due  to  sequential  cycles  in  an  MSCC 
in  Gf. 

Recall  that  cycles  resulting  from  circular  coominication  of 
records  are  detected  by  the  MODEL  compiler  based  on  external 
dependency  statements. 

Discussed  below  are  two  forms  of  inconsistency  and  their 
detection. 

11.6.2.1  CIRCULAR  FORM  INCONSISTENCY 

A  circular  form  inconsistency  occurs  as  the  result  of 
inconsistent  accessing  of  sequential  files,  or  sequential  access  of 
ISAM  files. 

DEFINITION  7. 

A  circular  form  inconsistency  is  indicated  by  a  module  in  a 
configuration  whose  execution  may  precede  only  after  its  own 
termination .  □ 

It  is  not  difficult  to  see  that  a  configuration  containing 
circular  form  inconsistency  if  and  only  if  there  exists  some  module  Mi 
in  the  configuration,  such  that  Mi*>Mi  can  be  derived  from  some 
initial  temporal  relations  in  a  configuration. 

In  order  to  efficiently  detect  all  possible  circular  form 
inconsistencies  in  a  configuration,  we  introduce  another  graph 
representation . 

DEFINITION  8. 

A  COMPONENT  GRAPH  Gc-<Vc,Ec)  is  a  graph  constructed  from  Gf 
satisfying:  Vc  -  Vf/| j ,  and  Ec  -  Ef/J ! .  □ 

Again,  it  is  not  difficult  to  see  that  a  Gf  contains  any  circular 


form  inconsistency,  if  and  only  if  there  exists  a  cycle  in  Vc. 


As  mentioned,  every  component  in  Gc  is  an  equivalent  class,  which 
corresponds  to  a  MSCC  consisting  modules  strongly  connected  by  POST 
and  MAIL  ( file )  edges .  The  following  algorithm  finds  such  MSCCs  in 
Gf . 


Algorithm  1,  Vc  construction  (Procedure  name:  BVC ) 


Input  :  Gf 
Output:  Vc 

1.  Let  COUNT-1,  STACK -empty  and  TYP(x)  be  the 
TYPE  attribute  for  a  node  x. 

2.  Set  all  the  nodes  in  Gf  to  be  Mnew*. 

3.  Do  the  following  while  there  is  a  "new"  node  x  in  Gf: 

4.  Call  search(x). 

5.  End.  □ 


Search:  Proc(ND)  recursive? 

11.  Set  ND  to  be  "old”. 

12.  Set  ND.dfnumberKXXJNT. 

13 .  Set  ND . low link— ND . df number . 

1*.  PUSH(ND)  onto  STACK. 

15.  C0UNT-C0UNT+1 . 

16.  Do  the  following  for  every  successor  z  of  ND. 

17.  If  TYP(ND)  f  "ISAM"  S  TYP(ND)**  "SAM" 

18.  then  do; 

19.  If  z  is  "new" 

20.  then  do; 

21 .  Call  search( z ) . 

22.  ND .  lowlink«min(  ND .  lowlink ,  z .  lowlinlc ) . 

23.  End. 

24.  Else  do; 

25.  If  z.dfnumber  <  ND.dfnumber  S  INSTACX(z) 

26 .  then  ND .  lowlink=min(  z .  df  number ,  ND .  lowlinlc ) . 

27.  End. 

28.  End. 

29.  End. 

30.  If  ND. lowlink-ND.df number 

31.  then  do; 

32.  Do  the  following  until  P=ND. 

33 .  P-POP( STACK ) . 

34 .  Call  ADD_C0MP(  P ) . 

35.  End. 

36.  Call  END_C0MP(ND). 

37.  End.  □ 


ADD_C0MP  is  a  procedure  that  creates  a  list  of  elements  that 
belong  to  a  MSCC.  Procedure  END_COMP  marks  the  end  of  the  MSCC. 


This  algorithm  is  a  variation  of  the  depth-first  search 
algorithm.  Its  correctness  and  complexity  proofs  can  be  found  in 


CAho,74],  The  complexity  is  MAX(Nf,Ef).  Line  17  ensures  that  the 
traversing  on  Gf  is  conducted  only  on  connections  implied  by  -> 
relations  (through  POST  and  MAIL  files). 


Algorithm  2.  Construction  of  Ec.  (Procedure  Name:  BEC ) 

Input  :  Vc,  Gf 
Output :  Gc 

1.  Do  the  following  for  every  component  node  P  (of  Vc). 

2.  Do  the  following  for  every  element  e  in  P. 

3.  If  successor(e)  is  a  file  node 

4.  then  do; 

5 .  If  TYP( successor( e ) )-SAM  or  MAIL  or  POST 

and  successor^  2  )( e )  f  nil 

6.  then  find  the  component  node  SC  which  contains 

7 .  successor( 2 )( e )  as  a  member  and  make 
an  edge  from  C  to  SC. 

8.  If  TYP(  successor(  e )  )— ISAM  and  TYP(successor(2)(e))-ISAM 

9.  then  do; 

10 .  if  successor(  3  )( e )  f  nil 

11.  then  find  the  component  node  SC  which  contains 

12 .  successor( 3  )( e )  as  a  member  and  make 
an  edge  from  c  to  SC. 

13.  if  predecessor  x  of  successor( 2 )( e )  +  nil 

14.  then  find  the  component  node  SC  which  contains  x 

15.  as  a  member  and  make  an  edge  from  C  to  sc. 

16.  End. 

17.  End. 

18.  End. 

19.  End.  □ 


Note  that  line  13  of  the  algorithm  tests  if  a  target  node  of  an 
ISAM  F-F  edge  has  any  predecessor,  if  it  does,  a  new  edge  in  Gc  is 
created  ( see  definition  of  basic  connections  and  definition  of  Gc ) . 


Algorithm  2  has  complexity  0( Nc*Nc ) ,  because  every  node  in  Gf  may 
be  connected  to  every  other  nodes  in  Gf. 


The  data  structures  for  constructing  Gc  is  as  follows: 


DCL  1  C0MP_N0DE  BASED( C_PTR), 


2 

COMP  NO 

FIXED  BIN, 

/* 

COMPONENT  ID  */ 

2 

NEW 

BIT(l), 

/* 

FOR  MSCC  FINDING  */ 

2 

DFNUMBER 

FIXED  BIN, 

/* 

FOR  MSCC  FINDING  */ 

2 

LOWLINK 

FIXED  BIN, 

/* 

FOR  MSCC  FINDING  */ 

2 

SCDED 

BIT(l), 

/* 

MARK-1  IF  SCHEDULED  */ 

2 

PRES 

FIXED  BIN, 

/* 

NUMBER  OF  PREDECESSORS  */ 

2 

ELEJLIST 

PTR, 

/* 

POINTS  TO  A  C_LIST  V 

2 

SUC_LIST 

PTR, 

/* 

POINTS  TO  A  LK_LIST  */ 

2 

MAX_D 

FIXED  BIN, 

/* 

DIAMETER  */ 

2 

NEXT 

PTR; 

/* 

TO  NEXT  COMP_NODE  */ 

DCL  1  C_LIST  BASED( CL_PTR ) , 
2  ROOT.MK  BIT(l), 

2  ND_POINT  PTR, 


/*  FOR  MSCC  FINDING  */ 

/*  POINTS  TO  A  NODE  STRUCTURE  */ 


2  NEXT  PTR;  /*  POINTS  TO  NEXT  C_LIST  •/ 


The  list  of  all  components  in  Gc  is  pointed  by  a  global  pointer 
COMP_HD. 


After  the  construction  of  Gc,  the  error  detection  routine 
( SEQERR )  first  finds  all  the  MSCC  in  Gc  using  the  same  algorithm  as 
algorithm  1  without  line  17  and  then  use  the  following  algorithm  to 
report  error. 


Algorithm  3.  Report  Sequencing  Error. 

(Procedure  Name:  RPTERR). 

Input  :  List  of  MSCCs  in  Gc. 

Output:  Error  message,  if  any. 

1.  Do  the  following  for  every  member  x  in  the  list  of  MSCCs. 

2.  If  x  contains  more  than  one  element  then  ERROR  (SEQ1). 

3.  If  x  has  an  edge  in  Gc  which  leads  to  itself  then  ERROR  (SEQ2). 

4.  End.  □ 


The  error  messages  are  shown  as  follows: 


( SEQ1 )  AN  INCONSISTENT  MULTI -NODE  MSCC  FOUND  IN  CONFIGURATION 
CONSISTS  OF: 

-  element  1 

-  element  2 


( SEQ2 )  AN  INCONSISTENT  COMPONENT  FOUND  IN  CONFIGURATION 
CONSISTS  OP: 

-  element  1 

-  element  2 


Note  that  if  no  error  is  detected,  VC  is  used  in  diameter  finding 
calculation  (section  11.8). 


11.6.2.2  NON-CIRCULAR  FORM  INCONSISTENCY 


Non-circular  form  inconsistency  earn  be  depicted  as  follows. 


PI  and  F2  are  sequential  files.  Both  Ml  and  M2  consume  files  PI 
and  P2.  It  is  necessary  to  schedule  Ml  and  M2  sequentially . 


We  will  refer  to  the  problem  as  SFS  (Sequential  Pile  Sharing). 


A  solution  is  to  impose  a  sequential  relation  between  Ml  and  M2. 
The  following  algorithm  identifies  the  problem  and  resolves  it  if  it 
is  possible. 

Algorithm  4.  Solving  SPS  problems  in  Gf.  (Procedure  name:  SLV5PS) 

Input  :  Gf  and  Gc 

Output:  A  modified  Gc,  if  a  solution  is  found 

Data  structure  used: 

A  queue  Q  of  component  identifiers. 

bet  Si  be  a  list  of  files  with  type-"SAM"  and  device— «TAPE" 
which  are  consumed  by  module  Mi. 

Let  PRi  be  a  list  of  component  identifiers  preceeding  a 
component  Ci. 

Functions  used: 

PUTQ(e)  is  a  procedure  which  puts  e  to  be  on  the  end  of  Q  and 
TAKEQ( )  is  a  function  which  returns  the  first  element  in  Q. 

1.  Set  COUNT-O. 

2.  Por  all  module  node  Mi  in  Vf  do  the  following: 

3.  Set  S  -  0 

4.  Por  all  predecessor  v  of  Mi  with  device— "TAPE"  do: 

5.  s  -  s  n  (v). 

6.  End. 

7.  If  S  contains  more  than  one  element 

than  do; 

8.  COUNT-COUNT+1. 

9.  Set  -  S. 

10.  End. 

11.  End. 

12.  If  coumM 

13.  then  do; 

14.  Set  0-empty. 

15.  Por  all  Ci  in  Vc  do  the  following: 

16.  If  Ci  has  no  predecessors  then  POTQ( Ci ) . 

17.  Set  PRi  -  JB. 


20.  Do  while  Q  is  not  empty: 

21.  Ci-TWCEQ(  ). 

22.  For  all  successors  Cj  of  Ci  do: 

23.  PRj  -  PRj  U  PRi  U  (cj). 

24.  If  Cj  is  “new"  then  POTQ(Cj). 

25.  Set  Cj  -  “old". 

26 .  End . 

27 .  End . 

28.  For  i-1  to  COUNT  do: 

29.  For  j»i+l  to  COUNT  do: 

30.  If  Si  fl  Sj  has  more  than  one  element  then  do: 

31.  Let  Cl  be  the  component  containing  Si  and 

C3c  be  the  component  containing  Sj. 

32.  If  Cl-Oc  then  report  ERROR  (SFSl). 

33.  If  Cl  A  PRk  &  Ck  A  PRI 

34.  then  do; 

35.  Add  am  edge  from  Cl  to  Oc  in  Gc. 

36.  Call  C0RR(  k,  1) . 

37.  End. 

38 .  End . 

39.  End. 

40.  End. 

41.  End.  □ 

CORK  (k,l)  recursive: 

PRk  »  PRk  U  PRI. 

For  all  successors  Cx  of  Oc  call  C0RR(x,  1). 

End.  a 

This  algorithm  first  finds  for  each  module  a  set  of  “TAPE" 
predecessors  (lines  1-8 ) .  If  variable  COUNT  is  greater  than  one,  it 
implies  possibility  of  existence  of  SFS  problem  in  Gf. 


Lines  14-27  compute  the  transitive  closure  of  "*>"  relation  along 
every  path  in  Gc  and  associate  the  computed  results  with  each 

component.  In  other  words,  for  all  components  in  Gc,  if  Ci=»>Cj  then  i 
€  PRj. 

Lines  28-38  compute  pairwise  intersection  among  all  the  module 
nodes  that  have  Si  containing  more  than  one  element.  If  the 

intersection  of  Si  and  Sj  contains  more  than  one  element,  the  two 

modules  Mi  and  Mj  have  to  be  in  a  sequential  relation.  If  Mi  and  Mj 
are  in  the  same  component,  no  sequential  relation  can  be  imposed  (see 
definition  of  Gc);  an  error  is  reported.  Line  33  tests  if  Mi  is 
sequentially  related  to  Mj  in  either  direction.  If  they  are  not 

related,  a  new  edge  is  added  in  Gc  to  impose  a  relation  among  Mi 

and  Mj,  and  transitive  closure  of  newly  added  relation  is  computed  by 
procedure  CORK. 


Note  that  the  sequence  of  imposing  sequential  relation  is  not 
important  in  finding  the  solution  for  a  SFS  problem. 

BEEIMIHQH 

A  solution  for  a  SFS  problem  is  a  partially  ordered  set  Q  of  N 
■Modules  sharing  M  sequential  tape  files,  where  N>1  and  M>1.  And  Q  is 
compatible  with  Gc  -  the  Gc  including  Q  is  acyclic.  □ 

Proposition  1 •  if  Algorithm  4  does  not  report  error,  then  either 
there  is  no  SFS  problem  in  Gf  or  it  has  found  a 
solution  of  the  SFS ' . 

Proof. 

If  Algorithm  4  does  not  report  an  error,  this  implies: 

i)  The  condition  in  line  32  is  falsified 

— >  If  a  Q  is  found,  it  is  compatible  with  Gc. 

ii)  There  are  only  two  cases  existing  from  lines  33-38: 

a)  The  condition  in  line  33  is  falsified 

— >  there  exists  a  sequential  relation  between  the  Cl 
and  CX  in  Gc. 

b)  The  condition  in  line  33  is  true 

— >  lines  35  imposes  a  sequential  relation  from  Cl  to  CX. 

— >  If  the  condition  in  line  32  is  not  true  ->  A  Q  is  found.  □ 

Proposition  2:  If  there  exists  a  solution  for  a  SFS  problem,  then 
Algorithm  finds  it. 

Proof. 

If  a  solution  exists,  then  Q  exists  and  it  is  compatible  with  Gc. 
Suppose  Algorithm  4  does  not  find  Q.  There  is  only  one  possibility: 


line  32  reports  an  error. 


The  condition  in  line  32  is  "ClOt" 

— >  there  exists  two  elements  Cl,Ck  in  Q,  such  that  Cl||Ck. 

— >  If  the  condition  is  wrongly  programed,  then  lines  33-38  are 
executed.  From  Proposition  1,  either  Cl>>Cle  or  Ck*>Cl  will  be 
imposed.  In  conjunction  with  Cl|  |C3c,  by  the  definition  of  Gc, 
there  must  be  a  cycle  in  the  Gc  including  Q  -  contrary 
to  the  assumption. 

— >  If  the  condition  is  correctly  programed,  then  Q  is  not 
compatible  with  Gc  -  contrary  to  the  assumption .  □ 

The  complexity  of  the  algorithm  can  be  analyzed  as  follows. 
Lines  1-8  take  NM*( Nf-NM)  steps  to  compute  Si's,  where  NM  is  the 
number  of  module  nodes  in  Gf. 

we  assume  that  the  graph  Gc  is  cycle  free.  Therefore  lines  10-21 
take  Nc+Ec  steps  to  compute  PRi's. 

Finally  lines  23-35  takes  at  most  Nc*( n*( n-1 )/2 )  steps  to  check 
all  the  possible  pairs  of  modules,  where  n  denotes  the  number  of 
modules  consuming  more  than  one  tape  file. 

The  total  complexity  of  the  algorithm  is  therefore  0( Nc*n*n ) . 


11.7  SCHEDULING  (PROCEDURE  NAME:  SCHEDULE) 

11.7.1  MORE  CONSISTENCY  ANALYSIS 

A  configuration  that  has  passed  the  sequence  checking  may  still 
cause  some  problems  at  runtime.  For  example,  the  following 
configuration  is  inconsistent  in  that  we  can  derive  two  conflicting 
temporal  relations  from  it:  M1->M2  and  M1->M2 . 


DEFINITION  10. 


A  configuration  is  inconsistent,  iff  there  exist  two  modules  Mi, 
Kj  in  Gf,  such  that  Mi->Mj  can  be  derived  by  one  path  and  Mi->Mj  or 
Mj— >Mi,  by  some  other(s).  □ 

Note  that  the  inconsistency  definition  includes  circular  form 
inconsistency. 

Osing  the  similar  idea  for  inconsistency  detection,  the  above 
definition  calls  for  a  new  extended  parallel  relation  J | |  which  holds 
among  every  pair  of  modules  Mi  and  Mj  either  Mi->Mj  holds  or  Mj->Mi 
holds.  Evidently  1 1 1  is  also  an  equivalence  relation  and  the 
equivalent  classes  under  | | |  properly  include  the  equivalent  classes 
of  II. 

To  verify  the  consistency  of  a  configuration,  we  define  the 
following  graph. 

OBglMITIQH  11. 

An  EXTENDED  COMPONENT  GRAPH  Ge-<  Ve , Ee )  is  a  graph  whose  sets  of 
nodes  Ve  and  edges  Ee  are  defined  as  follows: 

Ve-  Vf/| || 

Ee-  ”->n/lllf  or  in  other  words,  <C1,C2>  €  Ee,  iff  there  are 

such  modules  Ml  e  Cl  and  M2  €  C2  that  Ml  ->  M2.  □ 

Me  will  denote  the  number  of  nodes  in  Ge  by  NDe  and  number  of 


edges  in  Ge  by  EGe.  Now  it  is  also  not  difficult  to  see  that  if  Ge  is 
cycle  free,  then  the  execution  of  a  configuration  is  feasible. 


The  detection  of  an  inconsistent  configuration  is  accomplished  by 
first  constructing  Ge  and  then  finding  MSCC  in  Ge  (using  the  same 
algorithm  as  for  Gc  construction).  Clearly,  all  the  module  nodes  in 
an  extended  component  can  be  initiated  at  the  same  time  by  the 
definition  of  ->  relation. 


11.7.2  SCHEDULING 


To  achieve  maximum  concurrency,  we  start  execution  of  each  module 
as  early  as  possible.  The  only  delay  on  initialization  is  due  to  the 
sequential  relations  existing  between  modules. 


By  the  definition  of  Ge,  we  can  see  that  Ge  can  be  used  directly 
as  the  schedule  graph. 


Following  are  the  algorithm  for  Ge  construction. 


Algorithm  5.  Construction  of  Ve.  (Procedure  name:  BVE ) 

Input  :  Vc,  Gf 

Output:  ve  (also  referred  as  a  set  of  extended  component  nodes). 

1.  Set  all  the  Mi  nodes  in  Gf  to  be  "new". 

2.  Set  all  the  edges  in  Gf  to  be  "new”. 

3.  Do  the  following  for  every  member  Qi  in  Vc  which  contains 

"new"  nodes. 

4.  Allocate  a  component  node  P  for  Qi  and  make  all  the  module  nodes 

in  Qi  be  the  element  in  P. 

5.  Do  the  following  for  every  element  e  in  P. 

6.  Mark  e  "old". 

7.  Do  the  following  for  every  predecessor  or  successor  x  of  e 

which  is  "new"  and  connected  to  e  by  a  "new"  edge. 

8.  Mark  x  "old”. 

9.  Mark  the  edges  e->x  and  x->e  "old". 

10.  If  TCT(X)«MAIL  or  TYP( X  )-POST 

11.  then  make  x  the  new  element  in  P 

12.  End. 

13.  End. 

14.  End.  □ 


Algorithm  6.  Construction  of  Ee.  (Procedure  name:  BEE) 

Input  :  Ve,  Gf 
Output :  Ge 

1.  Do  the  following  for  every  component  node  P  (of  Ve). 

2.  Do  the  following  for  every  element  e  in  P. 


3.  If  successor(e)  is  a  file  node 

4.  then  do; 

5.  If  TYP( successor* e ) )-SAM  and  successor( 2 )( e )  ?  nil 

6.  then  find  the  component  node  SC  which  contains 

7.  successor*  2 )( e )  as  a  Member  and  make 
an  edge  from  C  to  SC. 

8.  If  TYF( successor e > )-lSAM  and 

T»( successor* 2 )( e ) )-ISAM 

9.  then  do; 

10.  if  successor*  3 )( e )  f  nil 

11.  then  find  the  component  node  SC  which  contains 

12 .  successor* 3 )( e )  as  a  member  and  make 
an  edge  from  C  to  SC. 

13 .  if  predecessor  x  of  successor( 2  )( e )  ^  nil 

14.  then  find  the  component  node  SC  which  contains  x 

15.  as  a  member  and  make  an  edge  from  C  to  SC. 

16.  End. 

17.  End. 

18.  End. 

19.  End.  □ 


In  constructing  Ve,  in  the  worst  case,  the  algorithm  traces  every 
node  and  edge  in  Gf  exactly  once.  Thus  the  complexity  of  the 
algorithm  is  0(Nf+Ef). 

In  constructing  Ee,  the  function  successor( k )( e )  returns  the  k-th 
successor  of  e.  In  line  7,  the  algorithm  creates  edges  derived  from 
SAM  file  connections  in  Gf .  Lines  10-16  create  edges  implied  by  ISAM 
F— P  causality  relations. 


the  complexity  of  construction  of  Ee  is  0(NDe*NDe). 

The  data  structures  for  Ge  construction  is  the  same  as  for  Gf 
provided  the  field  H_H_UCS  is  used  to  point  all  the  elements  in  an 
extended  component .  The  list  of  Ve  is  pointed  by  the  global  pointer; 
ECOMP_HD. 


The  following  algorithm  reports  inconsistency  error. 

Algorithm  7.  Report  Inconsistency  Error. 

(Procedure  Name:  CSTERR) . 

Input  :  List  of  MSCCs  in  Ge. 

Output:  Error  message,  if  any. 

1.  Do  the  following  for  every  member  x  in  the  list  of  MSCCs . 

2.  If  x  contains  more  than  one  element  then  ERROR  (SCDl). 

3.  If  x  has  an  edge  in  Gc  which  leads  to  itself  then  ERROR  (SCD2). 

4.  End.  □ 


Detailed  error  messages  are  shown  below. 


(SCD1)  CYCLES  FOUND  IN  A  SCHEDULE  GRAPH  CONSISTING  OP: 
-PAR  NODE:  element  1 
-PAR  NODE:  element  2 


( SCD2 )  A  SIMPLE  CYCLE  IS  POUND  IN  A  SCHEDULE  GRAPH  CONSISTING  OP: 
-ELE:  element  1 
-EXE:  element  2 


11.8  MSCC  DIAMETER  EVALUATION  (PROCEDURE  NAME:  PDMAX) 

The  diameter  of  a  MSCC  in  the  configuration  graph  is  used  by  the 
termination  control  algorithm  for  terminating  iterative  solutions  of 
distributed  simultaneous  equations  (described  in  Part  III). 

DEEINrriQtt  12. 

Let  p(Mi,Mj)  be  the  number  of  module  nodes  in  the  shortest  path  from  a 
module  node  Mi  to  a  module  node  Mj ,  and  N  be  the  number  of  module 
nodes  in  a  MSCC.  The  DIAMETER  of  a  MSCC  is  equal  to 

MAX(ML(M1  ),ML(M2  ),  . .  .  ,ML(MN)  )  -  1 
where  ML( Mi )  is  defined  as 

MAX(p(Mi,Ml),p(Mi,M2  ),  .  . . , p(Mi,MN)  ).  □ 

In  the  current  implementation,  the  Configurator  computes  the 
diameter  for  each  MSCC  found  in  a  configuration  graph  and  passes  this 
value  to  each  individual  module  through  a  logical  name  assignment  JCL 
comsand: 

5 DEPINE  MAX_D  "diameter". 

The  individual  modules  can  then  get  the  diameter  through  the 
logical  name  MAX_D. 

To  compute  the  diameter  of  a  graph,  we  need  to  find  the  lengths 
of  the  shortest  paths  between  any  two  nodes  in  the  MSCC.  There  have 


been  a  number  of  algorithms  proposed  for  performing  this  task,  usually 
with  complexity  0(N**3)  [Berztiss,  71].  Since  we  expect  that  in 
majority  of  cases,  a  MSCC  hem  the  number  of  edges  proportional  to  N, 
rather  than  N**2,  we  selected  the  following  algorithm  with  complexity 
0<N*E). 


Algorithm  8.  Finding  diameter  of  a  MSCC.  (Procedure  Name:  FDMAX) 

Input  :  A  MSCC  ( from  algorithm  1 ) 

represented  as  a  set  of  multi-linked  lists 
Output:  Diameter  (MAX)  of  the  MSCC 

Data  structure  used: 

A  queue  Q  with  a  pair  of  integers  as  elements:  (e,d), 
where  is  the  identifier  of  a  node  and  d  is  the  distance 
value. 

Let  TAKEQ( )  be  the  function  returning  the  pair  of  first  element  in  Q, 
and  POTQ( e , d )  be  the  function  that  puts  e  at  the  end  of  Q,  d  is 
interpreted  as  the  distance  of  e  from  the  root. 

1.  MAX-0. 

2.  Do  the  following  for  each  module  node  Mi  in  the  MSCC: 

3.  empty  Q. 

4.  set  all  elements  in  the  MSCC  to  be  "new*. 

5.  POTQ(  Mi ,  0  ) . 

6.  Do  the-  following  while(Q  is  not  empty). 

7.  Let  (e,d)-TAKEQ( ). 

8.  For  each  successor  succ  of  e  do. 

9.  tf  succ  is  “new" 
then  do; 

10.  Set  succ  to  be  "old". 

11.  If  succ  is  a  module  node 
then  do; 

12.  PUTQ( 3ucc , d+1 ) . 

13.  If  d  >  MAX  then  MAX-d+1. 

14.  End. 

15.  Else  call  POTQ( succ,d). 

16.  End. 

17.  End. 

18.  End. 

19 .  End .  □ 


The  above  algorithm  correctly  computes  the  diameter  of  a  MSCC. 


Proof. 


Note  that  in  the  maximum  distance  calculation,  the  file  nodes  axe 
"transparent",  i.e.  a  path  Mi->Fl-»Mj  is  of  length  1  rather  than  2. 


The  algorithm  uses  a  global  variable  MAX  for  storing  the  final 
result.  MAX  is  constantly  modified  during  the  processing  (line  13). 


We  must  compute  ML  for  every  module  node  in  the  MSCC.  This  is 


done  by  lines  3-19.  Line  S  puts  the  “root**  of  a  search  tree  (Mi)  into 
Q.  Lines  6-18  find  ML( Mi ) .  The  search  tree  is  constructed  by  using  Q 
in  the  following  way.  The  immediate  successors  are  searched  by  line 
8.  If  the  successor  is  a  module  node,  line  12  gets  d+1  as  the 
distance  of  the  successor.  Otherwise,  the  same  d  is  pushed  onto  Q. 
The  global  variable  MAX  is  modified  whenever  modified  d  exceeds  it. 

Lines  9  and  10  ensure  that  every  node  in  the  MSCC  is  to  be 
visited  only  once  in  evaluation  of  ML( Mi ) ,  consequently  every  edge  in 
the  MSCC  is  visited  exactly  once  during  this  process. 

Since  every  node  cam  be  put  in  Q  only  once,  we  can  conclude  that 
the  loop  from  lines  6  to  18  must  terminate. 

Now  we  prove  the  correctness  of  the  algorithm  by  induction  on  the 
distamce  value  k.  To  do  that  we  first  consider  the  following 
equivalence : 

(1)  p< Mi , Ms )-k  <«>  (Ms,d )  has  been  in  Q  and  d-k. 

For  k-O,  we  have  exactly  one  node,  such  that  p( Mi , Ms )=o ,  i.e. 
Ms-Mi .  Por  this  node  Mi,  line  5  defines  a  pair  (Mi,d)  with  d-0. 
Conversely,  suppose  that  there  is  a  node  Ms  such  that  a  pair  (Ms,d)  is 
in  the  Q  and  d-0.  Line  12  implies  that  any  module  node  different  than 
Mi  in  the  MSCC  will  have  distance  d  at  least  by  one  greater  than  0. 
Thus  Ms-Mi. 

Now  suppose  that  the  equivalence  holds  for  all  k  <n.  Let  us 

consider  a  module  node  st,  such  that  p(Mi,st )-n+l.  There  must  be  a 
module  predecessor  s  of  st,  such  that  p(Mi,s)-n  and  st  must  be  new 
when  s  is  taken  from  Q.  Thus  under  the  inductive  hypothesis,  let 
(st,dst)  and  (s,ds)  be  the  elements  in  Q,  dst-ds+l-n+1 .  Conversely, 


if  for 


module  node  st,  (st,dst)  is  an  element  in  Q  and  dst-n+l, 


then  there  must  exist  some  module  node  s,  such  that  s  is  the 
predecessor  of  st,  and  (s,ds)  is  an  element  in  Q,  ds-dst-l-n-l-n. 
Bence  p(Mi,s)-n  and  finally  p(Mi,st)-p(Mi,s)+l-n+l.  ■ 
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Furthermore ,  since  line  13  conditionally  modifies  MAX  whenever  d 
is  modified,  it  is  trivial  to  see  that  MAX  records  the  diameter  of 
MSCC.  □ 

The  complexity  of  the  algorithm  can  be  shown  as  the  following. 
Let  N  be  the  number  of  module  nodes  in  MSCC,  and  e  be  the  number  of 
edges.  It  takes  0(N)  steps  to  go  through  the  outer  loop  from  line  2 
to  line  19.  The  number  of  steps  to  compute  line  6  to  line  18  is  E+N 
because  every  node  and  every  edge  have  to  be  visited  precisely  once. 
For  MSCC  with  N>1,  obviously  E  >N,  thus  the  total  complexity  for  the 

algorithm  is  0(N*E).  □ 

11.9  CODE  GENERATION  (PROCEDURE  NAME:  GCODE) 

The  code  generated  by  the  Configurator  is  dependent  on  the 
available  operating  system.  The  current  implementation  uses  VAX/VMS 
operating  system,  version  3.6.  The  Configurator  generates  a  set  of 
programs  in  JCL  and  PL/ I  that  initiate  and  execute  the  system. 

The  implementation  of  the  system  described  in  a  CSL  specification 
consists  of  programs  on  three  levels  under  VMS. 

i)  Main  (or  sub-main)  JCL  program  level  (one  for  each  configuration 
specification ) . 

ii)  Individual  JCL  program  level  (one  for  each  module  in  a 

configuration ) . 

iii)  Individual  program  level  (one  for  each  module). 


A  main  (or  sub-main)  JCL  program  performs  three  tasks,  namely 

i)  create  necessary  mailbox(es)  by  calling  VMS  mail  server  ( SRUN 
crembx), 

ii)  submit  individual  (or  sub-main)  JCL  programs  for  execution 
( 3SUBMIT ) ,  and 
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iii)  at  the  end  of  submission  of  modules  for  execution,  the  JCL 
program  determines  when  all  the  modules  executions  have  been 
completed.  (This  is  done  by  using  S SYNCHRONIZE  commands.)  This 
is  necessary  in  the  case  that  the  main  JCL  program  corresponds  to 
a  GRP  type  node,  which  possibly  may  have  to  be  synchronized  with 
other  modules. 


The  five  types  of  commands  in  an  individual  JCL  program  are 
arranged  in  the  following  way: 

i)  commands  for  synchronization  ( ^SYNCHRONIZE) 

ii)  commands  for  assigning  logical,  file  names  to  the  physical  ones 
( 3DEFINE ) 

iii)  MSCC  diameter  definition  (optional)  ( 3DEFINE  MAX_D) 

iv )  comnand  for  activating  a  module  ( 3RUN ) 

v)  commands  for  disconnecting  the  logical  file  assignments 
(  3DEASSIGN ) 

A  SUBMIT  command  in  VMS  puts  a  JCL  program  into  a  job  queue.  It 
also  gives  an  external  name  (JCL  accessible)  to  the  job  in  the  queue. 
VMS  will  then  schedule  the  jobs  in  the  job  queue,  according  to  the 
delay  commands  in  respective  jobs,  and  execute  them  in  a  simulated 
parallel  fashion.  A  SYNCHRONIZE  comnand  is  used  to  delay  the 
execution  of  a  command  until  the  completion  of  a  specified  job. 
Commands  DEFINE  and  DEASSIGN  connect  and  disconnect  the  logical  file 
names  respectively.  When  a  RUN  command  is  executed,  the  executable 
code  produced  from  the  PL/I  programs  generated  by  the  MODEL  compiler 
is  located  and  executed. 

The  following  graph  shows  the  execution  of  a  configuration 


system. 


Main  JCL 

Individual  JCL 

Individual  Module 

(MAIN.COM) 

(A. COM) 

(A. EXE) 

!  Screate  maiLbo? 

j Ssubmit  A - - 

{Ssubmit  B  . 


{Ssubmit  SUB\. 

!  Ssynchronize  \ 

!  Ssynchronize  B  rs.  ^ 

!  Ssynchronize  SUB  j  i 

^ - j.  I 

SUB-MAIN  JCL  ( SUB . COM ) 


i  Screate  mailbox  ! 
!  Ssubmit  X  —  j 

!  Ssynchronize  X  j 


! Ssynchronize 
j  Sdefine  . . . 


ISrun  A 
j  Sdeassign 


( B . COM ) 


! Ssynchronize 
i  Sdefine 
i  Srun  B 


( X . COM ) 

t—  -  — .  . 

| Ssynchronize 
j  Sdefine  . . ^ 


FIGURE  22.  Execution  of  a  Configuration  System 

The  above  figure  shows  the  first  two  levels  of  a  configuration  system. 
The  first  level  main  JCL  is  "MAIN.COM"  which  submits  all  its 
constituents:  A,B,  .  .  .  and  SUB,  which  is  a  GRP  node  in  the  main 
configuration  representing  a  sub-main  JCL  on  the  second  level.  The 
file  "SUB.COM"  is  generated  by  a  separate  run  of  the  Configurator. 
The  "EXE"  files  are  executable  codes  of  all  individual  modules 
generated  some  high-level  language  compiler. 

This  scheme  can  also  be  used  to  execute  programs  in  a  computer 
network. 


11.9.1  MAIN  JCL  PROGRAM  GENERATION 


The  main  JCL  program  is  generated  simply  by  scanning  the  modules 
in  the  system. 

Algorithm  9.  Generating  main  JCL  programs.  (Procedure  name:  GCODE) 

Input  :  List  of  modules  in  Gf 
Output:  The  main  JCL  program 


1.  Generate  "compile" ,  "link"  and  "run"  commands  for  the 
mailbox  creation  program. 

2.  Do  the  following  for  each  member  e  in  the  list. 

3.  If  TYP(e)  f  “+”  &  TYP(e)  +  "MAN" 

4.  then  generate  "SSUBMIT  e  /NAME=e  ". 

5.  End. 

6.  Co  the  following  for  each  member  e  in  the  list. 

7.  If  TYP(e)  ?  &  TYP(e)  *  "MAN" 

8.  then  generate  "SSYNCHRONIZE  e  ". 

9.  End.  □ 

The  generation  of  the  SYNCHRONIZE  command  is  based  on  the 
sequential  relations.  For  example,  if  component  Cl  is  a  predecessor 
of  component  C2  in  Gc  and  if  Ml  €  Cl  and  M2  €  C2,  then  the  JCL 

programs  for  Ml  and  M2  are: 

( Ml . com )  ( M2 . com  > 

SRUN  Ml  S SYNCHRONIZE  Ml 

3  RUN  M2 

Lines  5-8  are  designed  to  ensure  proper  synchronization  sequence  for 
all  GRP  modules.  It  has  the  effect  that  every  main  (or  sub-main)  JCL 
program  will  not  finish  until  each  and  every  submitted  job  finishes. 

A  GRP  module  represents  a  sub-configuration.  It  implies  a 
separate  run  of  the  Configurator  which  generates  a  sub-main  JCL 
program.  At  the  time  of  a  (relative)  global  configuration,  the 
details  of  the  sub-configurations  are  invisible.  For  a  module  node 
whose  sequential  predecessor  is  a  GRP  module,  direct  synchronization 
with  any  modules  in  the  GRP  predecessor  is  impossible.  Therefore  that 
module  has  to  be  synchronized  with  the  JCL  program  of  the  GRP 
predecessor  node,  since  every  main  (or  sub-main)  JCL  program  finishes 
only  after  the  completion  of  all  the  submitted  jobs,  proper 
synchronization  is  thus  achieved. 

11.9.2  INDIVIDUAL  JCL  PROGRAM  GENERATION 

To  achieve  maximum  concurrency,  every  individual  JCL  program 
synchronizes  only  with  its  direct  sequential  predecessor  modules  ( in 


The  following  is  the  algorithms  which  produces  individual  JCL 
programs. 


Algorithm  10.  Producing  individual  JCL  programs. 

(Procedure  name:  GCODE ) 

Input  :  Gf 

Output:  individual  JCL  programs  for  each  module 

0.  Do  the  following  for  each  module  e  in  Vf. 

1.  If  TYP(  e  )f‘"MAN" 

2.  then  do; 

3 .  Create  a  JCL  file  for  e  ( named  ' e  * . COM ) . 

4.  Do  the  following  for  every  sequential  predecessor  module  Mx 

5.  Generate  "SSYNCHRONIZE  Mx/NAME =MX" 

6 .  End . 

7.  If  TYP(e)  +  "GRP" 

8.  then  do; 

9.  Generate  "SDEPINE  logical  file  name" 

10.  If  the  MSCC  containing  e  has  diameter  >0 

11.  then  generate  "SDEPINE  MAC_D  diameter". 

12.  Generate  "3RUN"  and  "3DEASSIGN"  commands  for  e 

13.  End. 

14.  Else  do; 

15.  Generate  "SSUBMIT  Se/NAME=Se” . 

16.  Generate  " $ SYNCHRONIZE  Se". 

■  17 .  End . 

18.  Close  *e'  .COM. 

19.  End. 

20.  End.  □ 


Where  "Se"  in  the  algorithm  is  the  name  of  "e"  prefixed  by  an 

"S". 


(tote  that  although  there  may  be  a  chain  of  ”=> "  relations,  the 
synchronization  among  two  modules  cam  be  achieved  by  synchronizing 
only  the  closest  predecessor( s ) .  For  example,  if  Mil,Mi2  =>  Mj  =>  MJc, 
then  Mk  has  only  to  be  synchronized  by  Mj  and  Mj  has  to  be 
synchronized  by  Mil  and  Mi2. 

A  module  node  of  type  GRP  has  a  special  JCL  program  generated 
which  contains: 

a )  synchronization  cotrmand(  s ) , 

b)  a  submit  command  for  submitting  a  JCL  program  named  Se  (generated 
by  a  separate  run  of  the  Configurator  for  a  sub-configuration),  and 

c)  a  synchronization  conmand  for  synchronizing  the  termination  of  the 
JCL  program  with  the  termination  of  Se. 


Since  Se  has  its  own  termination  synchronization  with  the  modules 
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in  the  sub-configuration,  a  hierarchical  execution  pattern  is  then 
achieved . 

The  convention  of  naming  CSL  specifications  for 
sub-configurations  is  that  every  sub-configuration  must  have  a  name 
with  a  leading  character  "S”  and  its  representative  GRP  node  ( in  the 
relative  main  configuration)  must  have  the  name  without  the  leading 
“S" . 

The  complexity  of  this  algorithm  is  O(Nm),  where  Nm  is  the  number 
of  modules  in  a  configuration. 

11.9.3  PL/I  PROGRAM  GENERATION 

A  mailbox-creation  PL/ I  program  is  generated  by  scanning  all  the 
MAIL  files  in  the  system.  The  existence  of  a  mailbox  file  is 
indicated  by  a  MAIL  file  node  used  as  the  source  of  some  module  node. 
The  following  algorithm  traces  only  the  source  mail  files  and 
generates  the  mailbox  file  creation  PL/I  program. 

Algorithm  11.  Mailbox  creation.  (Procedure  name:  GCODE) 

Input  :  Gf,  list  of  files  in  Gf 

Output :  A  PL/I  program  which  creates  all  the  necessary  mailbox(  es ) 

1.  Set  fst**l'b. 

2.  Do  the  following  for  every  element  e  in  the  file  list. 

3.  if  TYP( e )*MAIL  and  successor(e)  is  a  module  node 

♦.  then  do; 

5.  If  fst 

then  create  heading  of  a  PL/I  program  and  declaration  part. 

6.  Set  fst* * 0 * ; 

7.  Generate  mailbox  creation  PL/I  statements  for  e. 

8 .  End . 

9.  End. 

10. If  fst*'0'b  then  generate  the  closing  part  of  the  PL/I  program.  □ 

The  use  of  the  variable  fst  is  to  prevent  the  generation  of  empty 
mailbox  creation  programs  when  there  is  no  source  MAIL  file  in  the 
system.  The  proof  of  the  correctness  of  this  algorithm  is  immediate 
and  omitted  here. 


The  mailbox  deletion  program  is  generated  in  the  same  way  as  for 
the  creation  program  except  that  the  VMS  utility  used  is  not  for 
creation  but  deletion. 

The  complexity  of  this  algorithm  is  O(Nf),  where  Nf  stands  for 
the  number  of  FILE  nodes  in  the  system. 


11.10  CONFIGURATION  DOCUMENTATION  (PROCEDURE  NAME:  GRPT) 

As  mentioned  before,  there  are  seven  reports  generated  by  the 
Configurator  to  aid  the  user  in  developing  and  debugging. 

The  CSL  listing  report  is  generated  by  procedure  LEX.PLI  during 
lexical  analysis. 

The  cross  reference  report  is  generated  by  a  procedure  XREP.PLI 
by  listing  the  two  symbol  tables  alphabetically. 

All  the  other  reports  axe  generated  by  a  procedure  GRPT.PLI. 

The  MSCC  report  is  generated  printing  all  the  elements  in  Vc 
connected  by  the  edges  in  Gf.  This  report  can  be  used  to  identify 
possible  circular  form  inconsistency. 

The  extended  component  graph  Ge  and  configuration  graph  Gf  axe 
printed  in  adjacency  matrix  form  based  on  Gf  and  Ge  respectively. 

The  report  of  module-file  cross  reference  is  produced  by  listing 
all  successors  of  any  node  in  Gf. 

The  listing  of  JCL  and  PL/I  program  is  generated  only  if 
configuration  programs  are  desired.  The  user  may  suppress  the 
generation  of  the  programs  and  use  the  Configurator  only  for  checking 
a  system  design. 

The  error  and  warning  message  report  reports  the  syntax  and 
semantic  errors  as  well  eta  the  errors  detected  during  completeness  and 
consistency  analysis. 


All  the  error/warning  messages  produced  by  the  Configurator  are 
listed  in  Appendix  €. 


CHAPTER  12 

OBJECTIVES  OP  THE  MODIFICATIONS 

The  major  objective  of  the  modification  to  the  MODEL  compiler  is 
to  enable  each  module  to  operate  concurrently  with  other  modules  in  an 
overall  configuration.  As  explained  in  Part  I,  an  overall  MODEL 
specification  may  be  partitioned  into  a  number  of  of  modules.  A 
specification  of  a  module  consists  of  only  variable  declarations  and 
equations.  Variables  in  each  module  are  also  declared  whether  they 
are  SOURCE  or  TARGET  -  meaning  that  they  sure  in  files  which  are 
external  to  the  modules.  The  module  then  interacts  with  its  external 
files.  Alternatively  files  may  be  internal  to  the  module.  To  have 
variables  shared  by  modules,  it  is  necessary  that  the  variables  be 
declared  external  to  these  modules.  The  implementation  of  the  overall 
specification  is  carried  out  on  two  levels.  The  Configurator  - 
described  in  Part  II,  implements  the  connection  of  modules  and  files 
to  form  a  network.  The  modified  MODEL  compiler  -  discussed  in  this 
part  -  generates  a  program  for  computing  am  individual  module  which 
communicates  with  other  modules.  The  old  MODEL  compiler  documented  in 
[Lu,  81]  was  developed  for  implementing  a  specification  by  a  single 
sequential  program  without  communication  with  other  modules.  Namely, 
the  operations  necessary  for  concurrent  programming  were  not  supported 
in  the  old  MODEL  compiler.  The  contribution  of  the  research  described 
in  this  part  is  to  incorporate  modularity  and  conmunication  into  the 
MODEL  language.  It  can  be  divided  into  four  areas  as  follows. 

External  dependencies  -  In  composing  a  specification  of  a  module, 
the  specifier  may  want  to  have  other  modules  provide  a  function  which. 
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given  values  of  certain  arguments,  returns  values  of  some  variables. 
To  provide  the  arguments,  the  specifier  must  declare  them  to  be 
members  of  record(s)  of  TARGET  files.  To  refer  to  the  result  values, 
the  specifier  must  declare  them  to  be  members  of  records  of  SOURCE 
files.  It  is  required  to  declare  the  dependency  of  the  result 
variables  or  the  argument  variable.  The  specifier  needs  not  declare 
or  ever  know  the  names  of  the  other  modules  which  provide  the 
function,  or  the  definition  of  the  function.  This  is  referred  to  in 
the  following  as  external  dependency  and  its  implementation  is 
described  in  Chapter  14. 

MAIL  and  POST  files  -  External  files  may  be  assumed  to  reside  on 
respective  devices.  Such  files  are  declared  as  having  a  sequential 
(SAM)  or  indexed  sequential  (ISAM)  organization.  However,  files  which 
connect  modules  need  not  have  to  reside  as  a  whole  on  a  device  but  may 
be  connunicated  piecewise  between  the  concurrently  computing  producer 
and  consumer  modules.  Such  files  must  be  declared  by  the  specifier  as 
having  a  MAIL  or  POST  organization.  MAIL  and  POST  files  are  similar 
in  function  to  the  mailbox  and  post  office  of  a  postal  system, 
respectively.  The  modification  to  the  MODEL  compiler  to  support  usage 
of  MAIL  and  POST  files  are  described  in  chapter  15. 

Concurrent  update  of  ISAM  files  -  ISAM  files  may  also  be  used  for 
connecting  modules.  In  this  cause,  the  modules  connected  may  be  both 
producers  and  consumers  of  the  file,  concurrently.  It  is  necessary 
therefore  to  provide  a  locking  mechanism  to  protect  the  shared  data, 
so  that  the  connected  modules  do  not  interfere  with  each  other.  If 
the  updating  is  only  of  a  single  record  at  a  time  ( in  the  generated 
program),  the  locking  mechanism  is  provided  through  the  facilities  of 
the  VMS  operating  system.  Otherwise,  the  user  is  warned  to  include 
the  locking  algorithm  that  allows  exclusive  access  to  the  ISAM  file  in 
the  module’s  specification.  This  is  described  in  Chapter  16. 

Inter-module  simultaneous  equations  -  When  there  is  in  the 
overall  specification  a  set  of  n  simultaneous  equations  with  n 
unknowns  which  span  more  than  one  module,  then  all  the  respective 
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module  programs  must  cooperate  in  the  solution  of  these  equations.  In 
the  old  MODEL  compiler,  the  Gauss-Seidel  method  is  used  when  a  set  of 
simultaneous  equations  is  confined  to  one  module  [Greenberg,  81].  Hie 
old  MODEL  compiler  is  extended  for  the  multi-module  cases.  Hie 
solution  of  the  equations  in  each  module  continues  to  use  the 
Gauss-Seidel  method.  However,  the  results  are  comnunicated 
iteratively  to  the  other  effected  modules.  A  Jacobi-like  method  is 
used  for  inter-module  iterative  solution.  Iterations  of 
communications  and  solutions  continue  until  overall  convergence 
conditions  are  attained.  This  extension  is  described  in  chapter  17. 

The  following  figure  shows  the  procedures  in  the  MODEL  compiler 
and  their  comnunications .  As  shown,  the  system  consists  of  five 
phases:  syntax  analysis,  array  graph  analysis,  range  and  data  type 
propagation,  scheduling  and  code  generation.  The  modified  or  added 
modules  are  marked  with  asterisks. 

Hie  description  of  the  modifications  to  the  MODEL  compiler  in  the 
following  chapters  follow  the  order  of  the  phases  in  the  MODEL 
compiler.  The  reader  who  desires  further  detail  may  refer  to 
respective  chapters  in  [Lu,  81]  for  additional  information.  The 
description  of  each  modification  starts  with  a  brief  description  of 
its  objective  or  function,  followed  by  description  of  methods, 
algorithms  and  data  structures  used  in  the  phases  as  appropriate. 
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FIGURE  23,  Processing  stages  in  MODEL  compiler 
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13.1  FUNCTION  OF  EXTERNAL  DEPENDENCY 


In  specifying  a  module,  the  user  may  utilize  services  of  other 
modules  to  perform  a  certain  function.  The  specified  module  must 
contain  the  arguments  of  the  function  in  records  of  target  files  and 
the  return  results  in  records  in  source  files.  Additionally,  to 
denote  that  there  is  a  causal  connectivity  between  the  arguments  and 
the  results,  the  user  must  also  provide  an  equation  stating  the 
dependency  of  the  latter  on  the  former.  This  is  referred  to  as 
external  dependency  statement. 


An  external  dependency  consists  of  a  pseudo  function  called 
DEPENDS_ON.  It  represents  a  dependent  relationship  among  its 
left-hand-side  target  record( s )  and  right-hand-side  source  record( s ) . 


The  following  is  an  example  illustrating  the  syntax  and  semantics 
of  the  external  dependency: 


MODULE:  Ml; 

SOURCE:  MF; 

TARGET:  NF; 

1  MF  FILE  ORG:  MAIL, 

2  MR(»)  RECORD, 

3  M  FLD  (PIC  ’9999'  ); 

1  NF  FILE  ORG:  MAIL, 

2  NR(  *  )  RECORD, 

3  N  FLD  (PIC  ’9999' ); 

I  SUBSCRIPT; 

N(I)  -  M(  I  )+l ; 

MR(I)  -  DEPENDS_ON(  NR(  I— 1 ) ) ; 

( END .MR ( I ) , END .NR( I ) )-I-1000; 


MODULE:  M2; 

SOURCE:  NF; 

TARGET:  MF; 

1  NF  FILE  ORG:  MAIL, 

2  NR(»)  RECORD, 

3  M  FID  (PIC  '<3999'  ); 

1  MF  FILE  ORG:  MAIL, 

2  MR(  * )  RECORD, 

3  M  FLD  (PIC  ’9999’  ); 

I  SUBSCRIPT; 

M( I )  »  IF  1-1  THEN  1 
ELSE  N( I— 1 )+l; 

NR(I)  -  DEPENDS_ON( M(  I ) ) ; 
(END.NR( I ) , END . MR( I ) )=I=1000; 
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Ml  and  M2  constitute  a  concurrent  system,  connected  through  files 
HP  and  NF,  NR  and  MR  axe  two  records  in  modules  Ml  and  M2 
respectively.  The  vector  of  records  MR  consists  of  all  the  odd 
numbers  from  1  to  1999  and  NR  of  all  the  even  numbers  up  to  2000. 

In  module  M2,  M(I)  is  defined  as  being  1  for  I»1  and  as  N( I )+l 
for  other  values  of  I.  Similarly  in  Ml,  N( I )  is  defined  as  being 
M(  I  )+i .  The  specifier  of  Ml  hats  to  state  the  external  dependency 
among  variables  M  and  N,  which  is  provided  externally,  i.e.  by  module 
M2.  Similarly,  the  specifier  of  M2  hats  to  state  the  external 

dependency  among  variables  N  and  M,  which  is  provided  externally,  i.e. 
by  module  Ml. 

13.2  SYNTAX  ANALYSIS 

DEPENDS_ON  is  a  pseudo  function  with  variable  argument  list.  It 
is  treated  as  an  ordinary  equation  with  LHS  as  the  dependent  variable 

and  rhs  as  the  independent  variable(s).  Thus  there  is  no  change  to 

the  syntax  analysis  phase . 

13.3  ARRAY  GRAPH  ANALYSIS  (PRECEDENCE  ANALYSIS) 

In  building  the  symbol  dictionary,  a  procedure  INITIAL  is  called 
to  check  the  attributes  of  each  symbol.  If  a  symbol  is  a  built-in 
function,  appropriate  mark  is  made  in  the  dictionary.  Since  the 

DEPENDS_ON  statement  is  treated  as  a  built-in  function,  it  is  placed 
in  the  43rd  position  in  the  array  FCNAMES  by  program  INITIAL.  The 
other  functions  are  either  MODEL  built-in  functions  or  PL/I  built-in 
functions . 

No  change  is  made  in  array  graph  construction. 

13.4  RANGE  AND  DATA  TYPE  PROPAGATION 

The  data  type  check  routine  CHECKER,  which  checks  for  number  of 
arguments  of  a  function,  by-passes  the  DEPENDS_ON  function.  This 


enables  the  DEPENDS_ON  function  to  have  arbitrary  number  of  arguments 
with  arbitrary  data  type.  Because  the  data  nodes  of  a  DEPENDS _0N 
function  must  all  be  RECORD  nodes,  there  should  be  no  data  types 
assigned . 

13 . 5  CODE  GENERATION 

There  is  no  changes  in  the  scheduling  phase. 

No  PL/ I  code  is  generated  for  the  statements  with  DEPENDS_ON 
function .  In  routine  GENASSR  ( called  from  CODEGEN ) ,  whose  function  is 
to  convert  a  given  MODEL  equation  into  a  PL/I  statement,  a  conditional 
RETURN  statement  is  added.  It  tests  the  existence  of  ”DEPENDS_ON"  and 
returns  back  to  CODEGEN  if  "DEPENDS_ON"  is  found  in  the  text. 


CHAPTER  14 

THE  MAIL  AND  POST  PILES 

14.1  FUNCTION 

Two  new  file  organizations,  MAIL  and  POST,  axe  added  to  the 
previous  MODEL  language  file  organizations:  SAM  and  ISAM.  The  user 
continues  to  view  the  external  environment  purely  in  terms  of  data. 
However,  if  the  data  connects  the  module  to  other  modules  and  does  not 
need  to  be  stored  as  a  whole  then  it  is  declared  as  having  MAIL 
organ izat i<"-n .  Otherwise  it  is  declared  as  a  SAM.  file.  The  records 
are  queued  (making  up  a  multiple  dimension  array)  in  a  MAIL  file  in 
the  order  of  arrival.  The  MAIL  file  thus  serves  the  function  similar 
to  a  mailbox.  The  POST  file  organization  is  used  if  a  record  contains 
an  address  of  the  destination  mail  file.  Thus  it  is  similar  to  the 
way  post  offices  distributing  messages  to  mailboxes.  A  POST  file  is 
thus  connected  to  multiple  MAIL  files.  There  can  be  multiple 
producers  and  consumers  of  data  of  a  MAIL  file,  however,  there  can  be 
only  a  single  producer  of  data  of  a  POST  file. 

14.2  SYNTAX  ANALYSIS 

The  augmented  BNF  of  the  FILE  declaration  in  MODEL  is  as  the 
follows . 

<PILE_DCL>  ::*■  1  <NAME>  IS  FILE  [,  ORG:  <ORG> ]  [ , KEY  <NAME>]  , 

<ORG>  SAM  |  ISAM  j  MAIL  !  POST 

FIGURE  24.  Syntax  of  a  file  declaration  in  MODEL 
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SAM  and  ISAM  axe  the  two  existing  file  organizations  in  the  old 
MODEL  language.  The  KEY  option  is  only  used  in  a)  a  POST  file  to 
indicate  the  field  in  a  record  that  contains  the  destinations  of  the 
records;  or  b)  an  ISAM  file  to  indicate  the  field  according  to  which 
a  record  is  accessible. 

The  syntax  analysis  program  stores  in  a  dictionary  the  attributes 
of  each  symbol.  This  is  done  by  the  semantic  routines  during  syntax 
analysis.  The  data  structure  of  the  dictionary  is  named  ATTRIBUTES 
having  the  following  fields. 

DCL  1  ATTRIBUTES  BASED  (ATTR_PTR), 

2  XDICT  CHAR(  32  ), 

2  XDICTYPE  CHAR(  4), 

2  XMAINASS  PTR, 


2  XRECIO  bit( 1 ) ,  /*  recio  or  3tream  io  */ 

2  XINXPOS  FIXED  BIN;  /*  INDIRECT  VECTOR  POSITION  */ 

XDICT  contains  the  name  of  the  entry  in  the  dictionary.  The 
field  XDICTYPE  indicates  the  type  of  the  entry  in  the  dictionary;  it 
may  be  one  of  the  following: 

i)  FILE  —  a  FILE  node 

ii)  FLD  —  a  FIELD  node 

iii )  RECD  —  a  RECORD  node 

iv)  ASTX  —  an  ASSERTION  node 


If  XDICTYPE  is  FILE,  the  pointer  field  XMAINASS 


points  to  an 


auxiliary  data  structure  named  FILE. 


DCL  1  FILE  BASED(DP),  /*  DATA  STRUCTURE  FOR  FILE  DCL  */ 

2  TYPE  CHAR(4),  /*  » ' FILE’  */ 

2  STMTS  FIXED  BIN, 

2  SMEMBERS  FIXED  BIN, 

2  TABULATED  FIXED  BIN,  /*  0-  NOTAB,  1-  TAB  */ 

•  2  DUMMY  PIXED  BIN, 

2  KEY_FLAG  FIXED  BIN,  /*  0-  NOKEY,  1-  KEYED*/ 

2  ISAMB  FIXED  BIN,  /*  0-SAM, 1-ISAM, 2=MAIL, 3= POST  */ 

2  MEMBERS(N), 

3  SSUB  FIXED  BIN, 

3  FIRST_SUB  FIXED  BIN, 

3  SEC0ND_SUB  FIXED  BIN; 


The  field  ISAMB  in  the  FILE  structure  contains  the  code  of  file 
organization.  The  coding  process  is  done  by  a  semantic  routine  named 
SVORG3  during  the  syntax  analysis . 

SVORG3:  ENTRY; 

/*  SAVE  FILE  ORGANIZATION  INTO  ASSOCIATED  DATA  AREA  */ 

IF  LEXBUFF- ' ISAM '  THEN  FILE . ISAMB-1; 

ELSE  IF  LEXBUFF^ ' MAIL '  THEN  FILE . ISAMB-2 ; 

ELSE  IF  LEXBUFF™ ' POST '  THEN  FILE . ISAMB-3; 

RETURN; 

Where  LEXBUFF  contains  the  symbol  recognized  by  a  lexical 
analyzer.  Fully  expanded  EBNF  description  of  the  concurrent  MODEL 
language  can  be  found  in  Appendix  B. 

14.3  CODE  GENERATION 

There  is  no  changes  i*n  the  array  graph  analysis ,  propagation  and 
scheduling  phases .  Some  knowledge  of  VMS  PL/ I  is  required  in  this 
section  [VAX,  80]. 

The  code  generation  phase  (CODEGEN)  consists  of  searching  the 
entries  in  the  flowchart  produced  by  the  scheduler  (SCHEDULE),  one  by 
one,  and  interpreting  them  into  PL/I  code.  Source  file  entries  are 
transformed  into  OPEN  operations;  target  file  entries  into  CLOSE 
operations;  source  records  into  READ  operations  and  target  records 
into  WRITE  operations.  The  transformation  process  varies  according  to 
two  attributes  of  the  node:  file  organization  and  target/source. 

Detailed  description  of  the  translation  process  is  presented  in  the 
next  four  sections. 

14.3.1  THE  OPEN  PROCESS 

As  shown  above,  the  ISAMB  field  in  data  structure  FILE  indicates 
the  file  organization  of  a  given  symbol.  The  following  table  depicts 
the  interpretation  of  the  MODEL  compiler  to  the  different  file 
organizations . 
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Let  "name"  be  the  name  of  the  file  with  type  ISAMB  in  the  table. 

ISAMB  ORG.  S/T  DESCRIPTION  OP  PL/ I  CODE 

0  SAM  S  Simple  OPEN  statement.  Option:  INPOT,  SEQUENTIAL. 

0  SAM  T  OPEN  process  is  omitted. 

1  ISAM  S  OPEN  with  read  only  options: 

INPUT,  SEQUENTIAL,  ENV( SHARED_WRITE ) . 

1  ISAM  T  OPEN  with  update  options: 

KEYED,  SEQUENTIAL,  UPDATE,  ENV( SHAR£D_WRITE ) . 

2  MAIL  s  i )  Create  a  mailbox  named  "name"S_MBX  using  VMS 

utility  SYSSCREMBX. 

ii)  Obtain  the  physical  name  bound  to  the  logical 
file  name:  "name"  by  using  the  VMS  utility 
SYSSTRNLOG. 

iii)  OPEN  the  file  with  obtained  physical  name. 

2  MAIL  T  No  need  of  am  OPEN  process.  The  file  is  open  to  write 

by  default. 

3  POST  T  No  need  of  an  OPEN  process.  The  file  represents  only 

intermediate  distribution. 

TABLE  6.  Interpretations  of  a  Source  Pile  node  (OPEN) 

REMARKS  ON  MAIL  PILE: 

The  mailbox  creation  statements  in  the  open  process  are  designed 
to  "compensate"  the  mailbox  creation  process  done  by  the  Configurator. 
In  general,  a  physical  mailbox  is  created  for  each  source  mail  file  by 
the  main  JCL  program  generated  by  the  Configurator.  The  mailbox  is 
deleted  when  the  module  that  uses  the  mailbox  as  source  terminates. 
However,  a  module  may  also  be  initiated  manually  and  repeatedly.  In 
such  cases,  the  mailbox  deleted  in  the  previous  run  has  to  be 
re-created  when  a  module  is  re-initiated.  The  mailbox  creation 
statements  in  the  OPEN  process  can  re-create  the  mailbox  if  it  is 
deleted  in  previous  run.  If  the  mailbox  exists  before  the  execution 
of  the  module,  the  mailbox  creation  statements  in  the  module  become 
redundant.  This  may  happen,  normally,  only  when  a  '•+"  module  is 
initiated.  In  VMS,  however,  a  redundant  mailbox  creation  request  is 
returned  immediately  instead  of  creating  a  new  version  of  mailbox. 
The  "+"  module  cam  still  get  access  to  the  existing  mailbox  which  may 


contain  some  messages  sent  by  other  modules  before  its  execution. 
Thus  the  correctness  of  the  implementation  is  guaranteed . 


The  logical  name  translation  process  is  to  obtain  the  physical 
file  name  assigned  at  runtime.  If  a  source  MAIL  file  is  assigned  to  a 
disk  file  at  runtime,  the  computation  proceeds  by  consuming  the  disk 
file,  as  if  a  mailbox  file  were  used.  This  facilitates  local 
debugging  for  individual  modules  by  avoiding  modification  and 
re-compilation  of  the  individual  MODEL  programs. 

14.3.2  THE  CLOSE  PROCESS 


The  following  table  depicts  the  CLOSE  process  for  a  file  node. 
Let  "name"  be  the  name  of  the  file  with  type  ISAMB  in  the  table. 


ISAMB 

ORG. 

S/T 

DESCRIPTION  OP  PL/ I  CODE 

0 

SAM 

S 

CLOSE  process  is  omitted. 

0 

SAM 

T 

Simple  CLOSE  statement. 

1 

ISAM 

S 

CLOSE  process  is  omitted . 

1 

ISAM 

T 

Simple  CLOSE  statement. 

2 

MAIL 

S 

Deletion  of  the  mailbox  created  in  the  OPEN  process 
using  the  VMS  utility  SYSSDEIMBX. 

2 

MAIL 

T 

No  need  of  a  CLOSE  process. 

3 

POST 

T 

No  need  of  a  CLOSE  process. 

TABLE  7.  Interpretations  of  a  Target  Pile  Node  (CLOSE) 

In  general,  the  CLOSE  process  is  performed  only  for  the  target 
files  in  a  module;  but  in  the  case  of  a  source  MAIL  file,  a  special 
mailbox  deletion  process  is  also  necessary. 

14.3.3  THE  READ  PROCESS 

The  READ  process  is  the  interpretation  of  a  source  RECORD  entry 
in  a  schedule.  The  interpretation  varies  based  on  the  organizations 
of  the  file  to  which  the  record  belongs. 


SAM  s  Simple  READ  statement. 

ISAM  S  Indexed  READ  statement. 

MAIL  s  Simple  READ  statement.* 

TABLE  8.  Interpretations  of  a  Source  Record  Kode( READ  > 


*MOTE:  The  MAIL  file  has  the  same  READ  process  as  for  a  SAM  file; 
this  is  to  allow  device  independence. 

Although  having  the  same  form  as  for  a  sequential  file,  a  READ 
operation  will  "wait"  if  it  is  issued  to  read  a  mailbox  and  there  is 
not  data  in  the  mailbox. 


14.3.4  THE  WRITE  PROCESS 


The  WRITE  process  is  only  for  target  and  update  files.  Let 
’name"  be  the  name  of  the  file  with  types  depicted  in  the  following 


table . 


ISAMB  ORG.  S/T 


DESCRIPTION  OF  PL/I  CODE 


0  SAM  T  Simple  WRITE  statement. 

1  ISAM  T  Keyed  WRITE  statement. 

1  ISAM  S&T  Keyed  REWRITE  statement. 

2  MAIL  T  i)  Obtain  physical  file  name  from  the  logical  name 

ii)  Assign  communication  channel  to  the  physical  name 

a)  If  channel  assignment  is  successful,  then 
WRITE  the  message  to  the  physical  mailbox  using 
VMS  utility  SYSSQIO 

b)  If  no  channel  can  be  assigned,  WRITE  the  message 
into  a  disK  file  named  "name'*. DAT 

iii)  Deassign  the  channel. 

3  POST  T  i)  Assign  channel  to  the  file  name  contained  in 

the  address  field  of  the  POST  file; 

a)  If  a  channel  is  assigned  successfully,  then 

WRITE  message  using  the  VMS  utility  SYSSQIO; 

b)  Otherwise  WRITE  message  into  a  disk  file 

named  "name" .DAT. 
ii)  Deassign  the  channel. 

TABLE  9.  Interpretations  of  a  Target  Record  Node( WRITE) 


REMARKS  ON  MAIL  PILE: 

The  runtime  physical  file  name  obtained  at  step  ( i )  can  be  either 
a  mailbox  name  or  a  disk  file  name  depending  on  the  logical  name 
assignment  in  JCL  before  execution.  If  a  disk  file  name  is  found,  the 
WRITE  process  simply  writes  the  record  to  the  disk  file.  Otherwise 
the  VMS  utility  routine  SYSSQIO  is  used  to  send  record  to  the 
designated  mailbox.  For  each  WRITE  action,  the  channel  assignment  and 
deassignment  are  respectively  executed  once;  this  is  to  allow 
efficient  use  of  comnunication  channels  available  on  a  particular  host 
computer. 


REMARKS  IN  POST  FILE: 


Instead  of  using  the  logical  file  name: 


to  acquire 


comnunication  channel,  as  done  for  a  MAIL  file,  the  POST-file  WRITE 
process  acquires  channel  to  the  address  field  in  the  POST  file.  This 
realizes  the  effects  of  runtime  distribution  of  records  to  different 
destinations . 


14.3.5  ON  ENDFILE 

Using  the  concurrent  programming  facilities  of  VMS-PL/I,  the 
exception  handling  must  be  considered.  The  exceptions  are  signaled  in 
different  ON-units  and  one  can  use  the  exception  codes  for  appropriate 
action. 

A  module  consuming  MAIL  file( s )  is  designed  to  disregard  all  the 
ENDFILE  marks  it  may  receive  from  the  mail  producers.  Because  every 
producer  executes  a  CLOSE  statement  when  it  finishes  local 
computation.  The  effect  of  executing  a  CLOSE  statement  is  to  put  an 
ENDFILE  mark  into  the  mailbox,  such  that  the  receiving  module  can  be 
informed  of  the  termination  of  a  producer  module.  These  marks  sure  not 
used  in  the  current  implementation. 
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An  ON  ENDFILE  unit  is  used  to  recover  from  reading  an  ENDFIIiE 
mark.  Before  each  READ  statement  for  a  MAIL  file,  there  axe  a  label 
statement  and  a  label  assignment  statement,  shown  as  follows. 

SRD_L ''  recname  "  : 

$RD_L=3RD_L" recname" ; 

READ  FILE(  '•name"  ) . . . 

In  the  ON  ENDFILE( “name" )  clause,  we  have  the  following: 

ON  ENDFILE( "name" )  BEGIN; 

GOTO  $RD_L; 

END; 

Where  "name"  is  the  name  of  the  MAIL  file  and  "recname"  is  the 
record  name  in  the  file.  When  an  ENDFILE  condition  is  signaled,  the 
control  of  the  program  is  transferred  to  the  ON-ENDFILE  unit.  The 
GOTO  statement  forces  the  control  back  to  the  original  READ  statement 
which  triggered  the  ON  unit.  Since  one  source  MAIL  file  may  contain 
more  than  one  RECORD  structure  which  will  be  interpreted  as  more  than 
one  READ  statement,  there  may  be  more  than  one  READ  statement  that  may 
signal  an  ENDFILE  condition.  The  use  of  the  label  variable  $RD_L  and 
the  label  assignments  ensures  the  proper  trace  of  the  read  statements. 


CHAPTER  15 


CONCURRENT  UPDATE  OP  ISAM  PILES 


15.1  PROBLEMS  AND  OBJECTIVES 


Sharing  ISAM  file  concurrently  requires  the  use  of  record  locking 
mechanism.  The  VMS-PL/I  compiler  offers  the  following  automatic 
record  locking  facilities. 


A  record  is  locked  when  both  of  the  following  are  true: 


*  A  READ  statement  is  issued  for  the  record. 

*  The  file  containing  the  record  was  opened  with  the  OUTPUT  or  UPDATE 
attribute. 

A  record  remains  locked  until  one  of  the  following  occurs: 

*  The  locked  record  is  rewritten  or  deleted. 

*  A  READ,  WRITE,  REWRITE,  or  DELETE  statement  is  executed  to  access 
another  record  in  the  same  file. 

*  The  REWIND  built-in  subroutine  is  called  to  rewind  the  file  to  its 
beginning. 

*  The  file  is  closed. 


Records  are  also  locked  for  the  duration  of  a  WRITE,  REWRITE,  or 
DELETE  statement  to  ensure  that  the  I/O  completes.  The  records  are 
unlocked  when  these  statements  complete. 

If  a  module  attempts  to  access  a  locked  record,  an  ERROR 
condition  will  be  signaled.  The  condition  can  be  sensed  in  an  ON 
ERROR  unit  (similar  to  an  ON  ENDFILE  unit). 

In  majority  cues,  an  ISAM  file  is  accessed  one  record  at  a  time. 
The  above  facilities  are  sufficient  to  provide  protection  to  the 
shared  data  in  such  cases.  However,  in  more  complex  applications,  a 


module  may  want  to  lock  several  records  in  order  to  update  them 
correctly,  meanwhile  allowing  other  modules  to  access  other  records  in 
the  same  file.  This  kind  of  application  will  be  called  here 
"multi-record  access".  Since  the  available  facilities  at  hand 
(VAX/ll— PL/I  and  VMS)  do  not  have  the  multi-record  locking  ability, 
the  MODEL  compiler  detects  whether  a  multi-record  access  is  implied  by 
the  specification,  it  issues  a  warning  to  the  user  confirming  that 
mutual  exclusion  will  not  be  provided  automatically. 

The  MODEL  compiler  is  modified  to  attempt  to  schedule  the  READ 
and  WRITE  or  REWRITE  processes  of  am  update  ISAM  file  inside  one  loop. 
This  ensures  that  if  possible,  a  user's  specification  will  be 
scheduled  into  one-record  access. 

15 . 2  SCHEDULING 

There  is  no  changes  in  the  stages  before  scheduling. 

In  scheduling  stage,  a  modification  is  made  to  force  the  merge  of 
a  READ  amd  a  write  operation  of  an  update  ISAM  file  into  one  loop  for 
mutual  exclusion  in  updating  shaured  records. 

To  illustrate  the  idea,  let  us  consider  the  following  example. 
If  X  is  an  update  ISAM  file,  a  MODEL  specification  which  manipulates 
the  file  may  produce  the  following  different  flowcharts: 

a)  Do  loop  1;  b)  Do  loop  1; 

READ  PILE(X);  READ  FILE(X); 

End;’  REWRITE( or  WRITE)  FILE(X); 

Do  loop  2;  End; 

REWRITE( or  WRITE)  FILE(X); 

End; 

If  the  module  is  running  concurrently  with  other  modules, 
schedule  (b)  is  more  desirable  due  to  its  implicit  use  of  VMS-PL/I  one 
record  locking  facilities  (see  section  15.1). 
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In  principle,  the  possibility  of  merging  two  loops  together  is 
decided  by  the  use  of  subscripts  in  a  MODEL  specification  and  an 
optimization  algorithm.  The  optimization  algorithm  first  determines 
all  the  possible  mergers  of  components  in  the  array  graph  and  then 
calls  a  function  EVALUATE  to  compute  the  memory  penalty  of  each 
merger.  The  merger  with  smallest  penalty  will  be  chosen  and  produced 
in  the  flowchart.  To  force  the  merger  of  a  READ  and  a  REWRITE  or 
WRITE  operations  (RW-merger),  the  function  EVALUATE  i3  modified.  The 
modified  EVALUATE  first  checks  the  existence  of  a  READ  and  a 
REWRITE(or  WRITE)  of  an  update  ISAM  file.  If  found,  the  function 
returns  (-  10,000,000  +  real  penalty).  Here  10,000,000  is  assumed  to 
be  the  maximum  memory  penalty  for  a  merger.  This  will  force  a 
RW-merger  with  smallest  memory  penalty  to  be  chosen,  i.e.  if  more 
than  one  RW-merger  have  been  found,  the  one  with  smallest  penalty  will 
be  chosen. 

After  scheduling,  a  flowchart  of  the  MODEL  specification  is 
constructed.  In  procedure  •’PREPARE”  (in  Figure  23),  the  check  of 
multi-record  accesses  on  ISAM  files  is  performed.  It  is  done  by 
scanning  the  flowchart  looking  for  consecutive  READ  (X)  statements 
(without  REWRITE  or  WRITE  in  between),  where  X  is  a  update  ISAM  file. 
A  warning  message  will  be  issued,  if  such  READS  have  been  found. 

15.3  CODE  GENERATION 

When  a  module  attempts  to  access  a  blocked  record  (i.e.  being 
updated  by  smother  module)  then  an  error  condition  is  created.  The 
objective  of  the  following  generated  code  is  to  recover  from  the  error 
and  attempt  smother  access  later. 

i)  Before  each  READ,  WRITE,  REWRITE,  and  DELETE  statement,  there  are 
a  label  statement  and  a  label  assignment  statement.  The  labels 
before  different  statements  are  named  differently.  Thi3  is  to 
keep  track  of  a  statement  which  signals  the  condition.  The 
following  figure  shows  a  sketch  of  the  produced  code. 


CHAPTER  16 

ITERATIVE  SOLUTION  FOR  DISTRIBUTED  SIMULTANEOUS  EQUATIONS 


16.1  PROBLEMS  AND  OBJECTIVES 


DSE  (Distributed  Simultaneous  Equations)  is 


system 


simultaneous  equations  which  span  more  than  one  module.  For  the 
system  is  to  be  solved  iteratively,  it  should  terminate  an  iteration 
only  if  all  of  its  modules  are  converged  ( or  have  run  out  of  iteration 
limit).  Otherwise  incomprehensible  results  may  be  produced. 

The  objective  of  the  modification  to  the  MODEL  compiler  is  to 
design  an  algorithm  that  can  be  attached  to  the  produced  PL/ I  program 
and  can  simultaneously  control  the  termination  of  each  iteration  of 
every  module. 

The  problem  is  equivalent  to  the  well  know  "distributed 
termination  problem"  studied  in  [Dijkstra,  83]  and  [Francez,  82]. 
Formally,  it  can  be  stated  as  follows .  Given  an  arbitrary  distributed 
system  consisting  of  N  modules  that  are  strongly  connected  and  run  in 
parallel,  the  system  termination  condition  is: 

B  =*  B1  &  B2  &  B3  &  ...  S  BN. 

<Bi>  is  called  the  "stable"  or  "termination"  condition  for  module 
Mi.  The  objective  is  to  terminate  the  system  as  soon  as  all  <Bi>s  are 
satisfied.  For  a  DES  system,  since  all  t*ie  modules  are  computing 
synchronically,  the  stable  condition  of  each  module  may  be  indexed  by 
the  iteration  number  t.  Consequently,  the  termination  control  problem 
can  be  stated  as  to  find  the  smallest  t,  such  that 


B(t)  =  Bl(t)  &  B2(t)  &  B3(t)  &  ...  &  BN(t) 


becomes  true  and  to  terminate  an  iteration  of  all  the  modules  at 
exactly  the  same  t. 

16.2  SOLUTION  TO  DISTRIBUTED  TERMINATION  PROBLEM 

To  control  the  termination  of  a  distributed  system,  a  termination 
control  algorithm  must  be  bound  to  each  individual  module;  but  in  no 
case  should  the  original  computation  of  each  module  be  altered. 

16.2.1  COMPARISON  WITH  THE  KNOWN  SOLUTIONS 

There  are  two  import  amt  differences  between  our  solution  and  the 
ones  studied  in  [Dijkstra,  83]  and  [Frances,  82]. 

i)  Network  connection. 

In  [Francez,  82],  an  undirected  spanning  tree  i3  chosen  in 
connecting  a  distributed  system.  In  [Dijkstra,  83],  an  undirected 
star-like  network  structure  is  used.  In  our  solution,  however, 
the  network  connection  can  be  a  SCDG  ( Strongly  Connected  Directed 
Graph ) .  Both  spanning  trees  and  the  star-like  networks  are 
special  cases  of  SCDG  if  the  undirected  edges  axe  treated  as  pairs 
of  directed  edges. 

ii)  Symmetric  treatment  of  modules 

The  requirement  of  knowing  the  "root"  of  the  connection  tree 
or  the  "center"  of  a  star  structure  is  dropped  to  allow  every 
module  to  be  equally  treated  and  the  solution  to  be  symmetric. 
Consequently,  the  same  control  algorithm  is  applicable  to  every 
node  (module)  in  the  SCDG. 

16.2.2  ASSUMPTIONS  OF  THE  TERMINATION  CONTROL  ALGORITHM 

Following  axe  the  assumptions  of  the  termination  control 
algorithm. 

i)  All  the  modules  participate  in  a  SCDG. 


ii)  Every  module  Ml  will  eventually  satisfy  its  corresponding  <Bi>, 
and  once  the  <Bi>  of  a  given  module  and  all  its  predecessors’  are 
satisfied,  that  module  will  keep  its  <Bi>  satisfied. 

iii)  There  is  only  one  format  for  control  messages;  i.e.,  the  control 
format  of  a  module’s  output  must  be  its  successors'  input  control 
message  format . 

iv)  The  maximum  diameter  (D)  of  the  SCDG  is  known  in  advance. 

Assumption  ( iv)  may  not  be  necessary  if  greater  communication 
overhead  can  be  tolerated  to  some  extent  (see  section  16.2.4). 

16.2.3  THE  TERMINATION  ALGORITHM  AND  ITS  DERIVATION 

In  the  sequel  we  use  standard  terminology  of  graph  theory  [Aho, 
74].  By  the  distance  L(x,y)  from  node  x  to  y,  we  mean  the  length  of 
the  shortest  (directed)  path  between  them.  The  network  diameter  (i.e. 
the  greatest  distance  between  any  two  nodes)  is  denoted  by  D. 

The  termination  detection  algorithm  involves  sending  tokens 
through  the  network.  Tokens  have  integer  values  from  the  interval 
<o,Dti>.  They  are  transmitted  as  a  part  of  communication  traffic 
generated  by  the  main  computation.  Thus,  in  the  case  of  distributed 
solution  of  simultaneous  equations  each  message  sent  between  processes 
consists  of  a  solution  of  local,  equations  and  a  token  representing  the 
3tate  of  a  node. 

Each  process  can  count  the  number  of  times  it  has  received 
messages  from  all  of  its  predecessors.  We  will  use  this  value  as  a 
local  index  of  node' 3  local  activities,  i.e.  reading  input, 
performing  computation  and  sending  output.  It  is  worthwhile  to  note 
that  in  the  considered  case  the  main  computation  is  partially 
synchronized,  because  no  process  can  complete  receiving  its  t+l-st 
input  messages  before  all  the  processes  have  received  their  t-th  input 
messages.  It  also  means  that  in  order  to  synchronize  deactivation  of 
processes,  each  one  of  them  has  to  stop  with  the  same  value  of  the 
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local  index. 

Let  T(t,x)  denote  a  predicate  indicating  whether  the  local 
termination  conditions  are  satisfied  in  node  x  for  local  index  i.  We 
assume  that  initially  T  is  false,  i.e.  for  any  node  x,  T(0,x)=P. 

By  I(t,x)  we  will  denote  the  minimum  value  of  tokens  received  by 
the  node  x  in  the  input  indexed  by  t .  Let  S(  t ,  x )  denotes  the  t-th 
state  of  the  node  x  defined  as: 

{0  -  if  T(t,x)=F 

min(S(  t-l,x)+l,  I(  t,x) )  -  otherwise 

The  state  is  well  defined  because  for  t=0  T(0,x)=F  and  therefore 

S(0,x)=0.  The  output  token  of  node  x  3ent  out  with  index  t  is  equal 
to  S( t , x  )+l .  ( This  token  is  received  by  successors  of  node  x  as  a 

part  of  their  t+l-st  input ) . 

Informally  speaking  a  node  x  is  a  generator  of  new  "O"  tokens 
when  T(t,x)=P  (i.e.  it  is  not  ready  to  stop)  and  it  i3  a  transmitter 
of  tokens  otherwise.  In  the  latter  case  the  node  selects  the  minimum 
token  among  its  actual  input  and  previous  output,  and  then  increases 
it  by  one  and  3ends  it  further  to  the  network.  When  all  the  nodes  cure 
ready  to  stop,  all  axe  transmitters  and  no  new  "0"  tokens  are 
generated.  Therefore  the  transmitted  tokens  grow  in  value,  as  do  the 
node  states,  we  3how  below  that  the  network  diameter  is  a  limit  value 
which  a  node  state  can  exceed  only  after  all  the  nodes  are  ready  to 
stop.  All  nodes  reach  that  state  with  the  same  local  index. 

To  show  this  more  formally,  we  notice  first  that  the  definition 
of  the  node's  state  implies  that 

S(t,x)iS(t-l,x)+l<.t  for  any  node  x  and  index  t>0. 

As  usual,  the  system  state  will  be  captured  by  an  invariant,  for 
instance  Q,  defined  as: 
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Q:  For  any  index  t  and  node  x  if  S(t,x)>0  then 

( Vy:L(y,x)<S(  t,x),Vj  : t-S( t ,x ) < j <t-L(  y , x ) )  ::  S(j,y)>0 

or  in  other  words,  for  any  node  y  and  any  index  j  if 
t-S(t,x)<j  <t-L(y,x)  then  the  node  y  is  ready  to  stop  for  the  index  j, 

i.e.  T(j,y)=T.  The  condition  S(j,y)>0  to  be  well-defined  requires 
j^O,  but  this  follows  from  inequality  t>S(t,x)  holding  for  any  node  x 
and  index  t>0. 

Now,  we  show  that  the  traffic  of  the  tokens  described  above  keeps 
Q  true.  Q  is  true  for  index  t=0,  because  for  any  node  x,  S(0,x)=0,  by 
definition.  Suppose  that  Q  does  not  hold  for  a  node  x.  Let  i0>0 
denote  the  smallest  index  of  such  event,  and  yo  denotes  a  node 
violating  Q.  Thus,  we  have 

<-Jj:iO-S(tO,X)<j.<tO-L(yO,X))  ::  S(j,yQ)=0. 

Let  jo  denote  such  j.  Since  Q  holds  for  tO-1,  we  have 
( Vj : tO— S( tO— 1 , x )— 1 < jitO— L( yO , x )— 1 )  ::  S(j,yO))>0. 

Since  S(t,x)  .<S(t-l,x)+l  for  any  index  t>0  and  node  x,  then  jO  may  be 
only  equal  to  tO-L(yO,x),  and  traversing  the  shortest  path  from  yo  to 
x  we  can  start  with  the  index  tO-L(yO,x)  and  the  state 

S( to— L(yQ,x),yO)=0,  to  reach  x  with  the  input  indexed  by  to  and  such 
that  I(  tO,x )_<L(yO,x ) .  But  the  definition  of  the  node’s  state  implies 
that  S(  to,x)<I(  tO,x),  what  contradicts  the  assumption  that 

S( to , x ) >  L( yO , x ) .  The  contradiction  proves  that  Q  is  indeed  an 
invariant . 

If  for  any  node  x  and  index  t,  S(t,x)>D  then  from  Q  we  conclude 
that  for  any  node  y  the  inequality  S(t-D,y)>0  holds  (since  L(y,x)<D) 
and  the  entire  computation  is  in  a  stable  state. 


Mow  we  have  to  show  only  that  if  for  some  index  t,  and  node  x, 
S(t,x)>D  then  for  any  node  y  also  S(t,y)>D,  i.e.  that  the  stable 


state  of  computation  is  recognized  in  all  the  nodes  synch ronically. 

This  is  implied  by  another  invariant  R,  defined  as: 

R:  For  any  node  x  and  any  index  t  there  is  such  a  node  y  that 
S(  t-S(  t , x ) , y )=0 . 

If  S(t,x)=0  then  R  holds  by  setting  y=x.  When  S(t,x)>0  we  can 
always  construct  a  sequence  of  nodes  y(0)=x,  y(l)..y(k),  k=S(t,x)  such 
that  for  1=1 ,  2 .  .  .  k . 


S(  t-1 , y( 1 ) )=S( t-1+1 , y(  1-1 ) )-l 


To  do  that,  let's  consider  evaluation  of  S( t-1+1, y( 1-1 )) .  If 
S(  t-1+1, y( 1-1 ) )=S( t— 1 , y( 1-1 )+l  then  we  set  y( 1  )=y( 1-1 ) .  otherwise  as 
the  element  y( 1 )  we  select  the  node  which  sends  the  token  with  the 
minimum  value  for  the  t-l+l-st  input  of  the  node  y( 1-1 ) .  The  last 
node  in  the  constructed  sequence,  i.e,  y(S(t,x)>,  satisfies  the 
condition  of  the  invariant  R. 

If  some  nodes  x,y  and  index  t  satisfies  the  conditions  S(t,x)>D 
and  S(  t,y  )i.D,  then  from  R  we  conclude  that  there  exists  such  a  node  z 
that  S( t— S( t,y),z)=0.  But  from  Q,  based  on  S(t,x)>D,  we  have  that 
S(t-k,v)>0  for  any  node  v,  and  any  k <L( v , x ) <D .  The  contradiction 
proves  that  all  the  nodes  of  the  network  reach  the  state  0+1  with  the 
same  local  index.  Therefore  reaching  this  state  can  serve  as  a 
trigger  for  deactivation  of  the  corresponding  process .  It  is  easy  to 
verify  that  in  fact  we  can  use  any  value  greater  than  D  as  a  trigger 
for  deactivation,  paying  price  however  of  continuing  the  main 
computation  unnecessarily .  [>+l  is  in  fact  the  smallest  trigger  value 
independent  of  the  pattern  of  getting  nodes  ready  to  stop. 


Finally,  we  cam  give  the  termination  algorithm  as  follows. 
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ALGORITHM  12.  DISTRIBUTED  TERMINATION  CONTROL. 

Le-t  D  be  the  diameter  , 

{Ti}  be  the  set  of  input  tokens  of  Mi  and  Oi  is  the  output 
token  of  Mi,  and 

PRE_Oi  be  the  value  of  the  previous  ( t-1 )  output  token  Oi . 
Initialization:  PRE_Oi=l . 


0. 

If  <Bi> 

1. 

then  if  PRE_0i 

<  MIN(  {Ti } ) 

2. 

then  Oi  =* 

PRE  Oi  +  1. 

3. 

else  Oi  = 

MIN( {Ti} )  + 

4. 

else  0i=0 . 

5. 

If  PRE_0i  >  D 

+1  then  stop. 

6. 

PRE_0i  =  Oi. 

□ 

The  implementation  of  the  algorithm  Is  described  in  section  16.3. 

16.2.4  FINDING  THE  DIAMETER  OF  THE  NETWORK  DYNAMICALLY 

Lack  of  knowledge  of  full  network  topology  at  compilation  time 
implies  that  the  network  diameter  may  be  unknown  until  run-time. 
Although  the  current  implementation  uses  the  Configurator  to  calculate 
the  diameter,  this  section  provides  a  simple  algorithm  which  may 
reside  in  each  module  and  compute  the  diameter  at  runtime  without 
using  a  centralized  configuration. 

For  the  given  network  we  denote  the  number  of  its  node  by  n  and 
its  connectivity  matrix  by  M.  Let  Ml  denote  a  (n  x  n)  matrix  with  all 
the  entries  equal  to  1.  The  network  diameter  is  the  smallest  exponent 
D  such  that  M  to  power  D  yields  Ml .  Each  node  in  the  network 
initially  knows  only  its  predecessors,  i.e.  one  row  of  the  matrix  M. 
To  minimize  the  comnunication  traffic  we  want  to  propagate  the 
smallest  possible  amount  of  data.  Thus,  instead  of  attempting  to 
build  up  entire  matrices  of  powers  1.2...D  of  M,  in  each  node  we  will 
construct  only  a  single  vector  representing  in  a  step  k  a  row  of  the 
k-th  power  of  M.  We  denote  the  elements  of  the  connectivity  matrix  M 
by  m(x,y)  x=l,2...,n,  y=l,2...,n,  where  m(x,y)=l  means  as  usual  that 
the  node  x  is  a  predecessor  of  the  node  y.  The  vector  m(k)(-,y) 


representing  the  k-th  power  of  M  in  the  y-th  node  i3  equal  to 


n 

m(k)(-,y)=  Z  m(k-l )( -,z)*m(z,y )«  Z  m(k-l)(-,z) 
z=l  m(z,y)=l 

But  m(z,y)»l  means  that  the  node  z  is  the  predecessor  of  the  node  y. 
Hence  constructing  such  a  vector  requires  only  sending  to  the  given 
node  vectors  of  the  previous  power  of  M  from  this  node's  predecessors. 
The  existing  comnunication  links  can  be  readily  used  to  carry  that 
task. 


To  further  decrease  the  communication  traffic  we  can  send  only 
this  part  of  a  vector  m(k-l)(-,z)  which  contains  l's  not  sent  in  the 
previous  steps  and  not  to  store  0's  at  all.  In  fact,  initially  each 
node  knows  only  l's  of  its  own  vector.  Thus,  in  each  step  k  we  have 
to  send  names  of  nodes  by  which  the  vector  m(k-l)(-,z)  was  extended  in 
the  previous  step. 

A  node  y  can  recognize  that  it  has  constructed  the  entire  vector 
m(k )( -,y )  when  in  some  step  k  all  the  node  names  received  have  already 
reached  the  node  y  before.  Indeed,  if  there  exists  a  node  x  such  that 
L(x,y)>k— 1  then  on  the  shortest  path  form  x  to  y  there  is  a  node  z 
such  that  L(  z ,  y  )=*k .  Therefore  the  name  of  z  reaches  the  node  y  at  the 
k-th  step  ( and  never  before  >  contradicting  the  assumption  about  the 
step  k.  The  number  of  unique  names  received  until  the  step  k  is  equal 
to  the  network  size  n,  and  the  longest  distance  in  the  network  from 
any  node  to  the  given  node  y  is  equal  to  k-1.  We  will  refer  to  that 
latter  value  as  a  relative  diameter  D(y)  of  the  node  y. 

In  quite  a  similar  way  to  the  termination  state  token  propagation 
the  nodes  can  propagate  also  tokens  representing  the  biggest  distances 
found.  Each  node  sends  out  the  maximum  value  of  distances  received  on 
input  and  its  own  relative  diameter  (or  step  number,  if  the  relative 
diameter  is  not  evaluated  yet). 

The  network  diameter  D  is  equal  to  such  node  x'3  output  token 


that  is  first  repeated  after  the  step  2*D(y). 


Following  is  the  complete  algorithm  for  finding  the  network 
diameter  D. 


ALGORITHM  13.  DISTRIBUTED  DIAMETER  EVALUATION  FOR  A  NODE  X. 

INPUT  FORMAT:  [k,Nl,N2, . . . ,Nn,T]( i ) 

where  Nl(  i),  .  .  .  ,Nn(  i)  are  the  input  module  identifiers  received 
at  the  i-th  input  by  module  X,  k(  i )  is  the  number  of  identifiers 
(module  names)  received  and  T( i )  is  the  biggest  distance  token. 

For  every  node  x,  attach  the  following: 

Let  D  be  the  diameter  of  a  global  network, 

CNT  be  the  index  counter  (t), 

Dx  be  the  local  diameter  value  of  node  x, 

(ID)  be  the  set  of  all  the  input  module  names  received  by  node  x, 
(T)  be  the  set  of  all  the  distance  tokens  received  by  node  x, 
TO,PRE_TO  be  the  output  distance  token  and  the  previous 
output  distance  token  respectively, 

STK  be  a  stack  of  identifiers  collected  from  the  input, 

NEW_ID(y)  be  a  Boolean  function  which  returns  "true"  if  y 
is  a  new  identifier  to  node  x,  and 
(OID)  be  the  set  of  output  identifiers. 


INITIALIZATION:  CNT=1.  D=0 .  Dx=0 .  PUSH(x)  onto  STK.  (OID)={x) . 

1.  New-'O'B. 

2.  Do  the  following  for  every  input  i  of  node  x: 

3 .  Do  the  following  for  j  =*  1  to  k(  i ) : 

4.  If  NEW_lD(Nj(i>)  then  PUSH(Nj(i>>,  New»’l'B. 

5 .  End . 

6 .  End . 

7.  If  New  then  Dx-CNT-2. 

8.  If  Dx=0  then  TO-CNT,  else  TO-MAX(Dx, (T) ). 

9.  If  CNT>Dx*2  &  PRE_TO=TO  then  D*TO. 

10 .  PRE_TO*tTO . 

11. If  D=0  then  set  (OID)  =  STK,  n  =  the  length  of  STK. 

else  set  (OID)  =0,  n  =  0,  STK  =*  empty.  □ 

To  verify  the  correctness  of  that  rule,  let  v  denote  such  a  node 

that  D(v)=D.  Since  L(v,y)<=D(y)  then  in  the  3tep  D(y  )+L(v,y  )+l  the 

token  D(y)+l  sent  from  v  reaches  y.  From  that  step  on  the  output 

tokens  from  y  will  grow  until  they  reach  D. 


According  to  that  rule,  every  node  v  will  know  that  D(v)=D  at  the 
3tep  2*D+1 . 


As  we  use  the  existing  communication  links  to  accomodate  traffic 
of  signals  created  by  this  algorithm  we  can  attached  these  signals  to 
the  messages  communicated  by  the  main  computation.  Therefore  the 
steps  of  the  algorithm  for  finding  the  network  diameter  will 


correspond  to  local  indexes  of  the  termination  detection  algorithm. 
Consequently  the  first  instant  at  which  the  entire  computation  for 
finding  diameter  can  be  stopped  corresponds  to  the  index  2*D+1. 

The  entire  termination  detection  algorithm,  including  finding  the 
network  diameter,  consists  of  three  phases.  At  the  beginning,  for 
indexes  1  to  D  three  streams  of  signals  are  flowing  through  the 
network : 

1.  Termination  state  tokens. 

2.  Names  of  nodes  for  constructing  connectivity  vectors.  This 
stream  gradually  dies  as  the  nodes  complete  building  their  vectors. 

3 .  The  biggest  distance  tokens . 

Then  for  indexes  CM-1  to  2*EH-l  two  streams,  the  fir3t  and  the 
third,  are  active.  Finally,  for  indexes  greater  them  2*D  only 
termination  3tate  tokens  flow  a3  all  the  nodes  know  the  diameter  D  emd 
the  auxiliary  algorithm  of  finding  the  diameter  stops. 

The  distributed  diameter  finding  algorithm  involves  additional 
communication  overhead  ( stream  2  above ) .  Therefore  the  use  of  the 
diameter  computed  during  configuration  compilation  by  the  Configurator 
is  preferred.  But  it  is  justified  only  when  every  module  in  the  DSE 
system  participates  in  only  one  DSE.  Otherwise  the  configuration  may 
represent  a  merger  of  all  the  individual  DSE’s  involved.  Such  a 
merger  may  have  smaller  diameter  than  some  of  its  constituents. 

As  the  distributed  diameter  finding  algorithm  is  not  generated  by 
the  current  implementation,  it  is  the  user's  responsibility  to  provide 
correct  diameter  ( the  maximum  value  of  all  the  possible  diameters ) 
through  a  CSL  specification,  if  necessary. 


16.3  GENERAL  DESCRIPTION 


To  give  an  idea  of  how  to  specify  a  module  involved  in  a  DSE 
system,  we  first  present  an  example  of  a  set  of  nested  simultaneous 
equations  without  involvement  with  a  DSE  system: 

I 

1.  MODULE:  NESTMOD; 

2.  SOURCE:  NESTIN; 

3.  TARGET:  NE STOUT; 

4.  1  NESTIN  PILE. 

2  NESTREC  RECORD, 

3  (K1,K2,K3,K4)  FLD  (PIC  'B9.V00' );  | 

5.  1  NESTOUT  FILE, 

2  OUTREC  RECORD, 

3  (X,Y,A,B,C,D)  ARE  FLD  (PIC  1 BBS( 5 )9 . V( 5 )9 1  ); 

6.  BLOCK  BLK1:  MAX  ITER  IS  100; 

7.  X  =  A  *  Y  +  B; 

8 !  BLOCK  BUC2:  MAX  ITER  IS  100;  i 

9.  A  -  0.2  *  B  +  K1  +  X  -X; 

10.  B  =  0.2  *  B  +  K2; 

11 .  END  BLK2 ;  ( to  be  continued ) 


12.  Y  3  C  *  X  +  D; 

13.  BLOCK  BLK3:  MAX  ITER  IS  100; 

14.  C  =*  0.2  *  D  +  K3  +  Y  -  Y; 

15.  D  »  0.2  *  C  +  K4; 

16.  END  BLK3; 

17.  END  BLK1; 


By  adding  the  assertion:  (Kl,K2,K3,K4)=DEPENDS_ON(X,Y,A,B,C,D) 
after  line  6,  NESTMOD  becomes  a  concurrent  module  participating  in  a 
DSE  system.  The  DEPENDS_ON  statement  indicates  that  there  is  an 
external  "environment"  that  computes  Kl,  K2,  K3  and  K4  based  on  X,  Y, 
A,  B,  C  and  D  in  some  unknown  way.  Module  NESTMOD  cannot  terminate  an 
iteration  if  the  convergence  condition  of  the  external  "environment" 
is  not  satisfied.  In  other  words,  the  presence  of  a  DEPENDS _ON 
statement  is  a  necessary  condition  of  a  module's  participation  in  a 
DSE  system. 


In  an  array  graph  (see  section  5.1),  a  set  of  simultaneous 
equations  is  represented  as  am  "undecomposable"  MSCC.  A  scheduler  can 
unravel  the  MSCC  and  produce  am  iterative  procedure  to  solve  it.  A 
MSCC  can  be  unravelled  in  many  different  ways  each  of  which  leads  to  a 
differently  blocked  structure.  Since  the  equation  written  sequence 


affects  the  speed  of  convergence  and  stability  of  the  system,  the 
MODEL  compiler  unravels  a  MSCC  according  to  the  equation  written 
order.  The  order  imposed  by  data  dependency  is  also  followed  in  a 


unravelled  MSCC.  This  gives  the  developer  of  the  system  some  freedom 
in  adjusting  the  speed  of  convergence  as  well  a3  stability  of  the 
solution  process. 

A  BLOCK  statement  in  MODEL  allows  a  user  to  specify  the  solution 
method  (currently  Gauss-Seidel),  relative  error,  maximum  iteration 
limit  and  nesting  structure  of  the  iterative  procedures .  A  user  can 
use  the  block  statements  to  identify  the  dense  clusters  in  a 
simultaneous  equation  system. 

The  presence  of  an  external  dependency  statement  in  a  MSCC  is  a 
necessary  condition  of  the  MSCC '3  involvement  in  a  DSE  system, 
therefore  it  changes  the  translation  process  for  the  module. 

16 . 4  SCHEDULING 

There  is  no  changes  made  in  the  3tages  before  scheduling. 

There  are  two  major  recursive  procedures  in  the  scheduler: 
SCHEDULE_GRAPH  and  SIMULJBLK.  The  modifications  are  made  in  procedure 
SIMUL_BLK . 

Every  BLOCK  statement  has  a  corresponding  block  structure  created 
during  syntax  analysis.  Each  block  structure  contains  all  the 
information  specified  in  the  BLOCK  statement  and  the  scope  of  the 
block.  The  MODEL  compiler  also  creates,  automatically,  a  "universal 
block"  which  scopes  from  zero  to  the  maximum  statement  number  reached 
during  the  syntax  analysis  of  a  MODEL  specification. 

Procedure  SCHEDULE_GRAPH  cam  topologically  sort  an  array  graph 
and  produces  flowchart  for  the  sorted  elements.  It  calls  procedure 
SIMUL_BLK,  if  a  multi-node  MSCC  is  found  in  the  graph.  SIMUL_BLX 
unravels  the  nested  block  structure  in  a  MSCC.  Following  is  the 
description  of  procedure  SIMUL_BLK. 


Algorithm  14.  MSCC  UNRAVELLING  (Procedure  Name:  SIMUL_BLK) 


Input  :  A  MSCC,  A  list  of  BLOCK  statements 

Output:  A  flowchart  of  the  unravelled  MSCC  with  proper  block  structure 


1. 

2. 


3. 

4. 

5. 

6. 

7. 

8. 
9. 


10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 

41. 
42  . 

43. 

44. 


Find  the  first  and  last  statement  numbers  in  the  MSCC. 

Find  the  smallest  BLOCK  cur_blk  which  contains  the 
entire  MSCC. 

Set  dpds=»nil . 

For  every  element  e  in  the  MSCC  do  the  following: 

If  e  is  a  DEPENDS_ON  statement 
then  do; 

Set  nesting=0 . 

For  each  member  b  in  the  BLOCK  list  do  the  following: 

If  the  b's  begin  statement  >  cur_blk's  begin  statement 
and  b's  end  statement  <  cur_blk's  end  statement 
then  do; 

if  the  statement  number  of  e  >  b’s  begin  statement 
then  nesting=nesting+l. 

If  the  statement  number  of  e  >  b's  end  statement 
then  nesting=nesting-l. 

End . 

End. 

If  nesting  <  2  then  do; 
set  dpds=»e. 

Cut  the  edge  from  e  ( a  DEPENDS_ON  statement ) 
to  its  target  variable( s ) . 

End . 

End. 

End. 

If  dpds^nil  then  do; 

/*  find  the  First  Element  FE  and  cut  backwards  edges  */ 

If  the  first  statement  in  the  current  block  is  a  BLOCK  statement 
then  set  FE  to  be  the  entire  BLOCK. 

else  set  FE  to  be  the  first  statement  in  the  current  block. 

Do  the  following  for  each  element  e  in  the  Msec. 

If  e  does  not  belong  to  FE  and  there  is  an  edge  emitting 
from  e  to  FE  then  cut  the  edge. 

If  e  belongs  to  FE  then  if  there  is  an  edge  emitting  from  e 
to  e,  cut  the  edge. 

End. 

End. 

If  the  cur_blk  bears  no  tag  or  bears  a  tag  "SEXT" 
then  do; 

If  dpds^nil 

then  mark  the  tag  of  cur_blk  "SEXT” 
else  mark  the  tag  of  cur_blk  ''DONE”. 

Collect  all  the  direct  or  indirect  target  FLD  nodes 
as  the  initialization  variables  for  this  MSCC. 

Create  a  header  of  a  simultaneous  block  for  this  MSCC. 
Recursively  call  SCHEDULE _GRAPH  to  schedule  the  modified  MSCC. 

I f  dpds=nill  then  Set  the~cur_blk  tag  =  ” 

else  set  the  cur_blk  tag  =  "SEXT”. 

Create  an  END  mark  of  the  simultaneous  block  in  the  flowchart. 
End. 

Else  recursively  call  SCHEDULE_GRAPH  to  schedule  the  modified 
MSCC.  □ 


The  above  algorithm  consists  of  three  major  steps: 
i)  Find  proper  edge( s )  to  cut. 

This  step  can  be  further  divided  into  two  parts: 
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a)  Find  DEPENDS_ON  statements  on  the  current  level  of  BLOCK  group 
nesting. 

This  is  done  by  lines  1-21.  Line  1  determines  the  scope 
of  the  given  MSCC.  Line  2  finds  the  smallest  block  which 
contains  the  entire  MSCC  and  establishes  the  current  level  of 
nesting  in  BLOCK  groups  ( cur_blk ) .  Since  the  MODEL  compiler 
creates,  automatically,  a  "universal  block"  enclosing  all  the 
statements  in  a  MODEL  specification,  cur_blk  always  exists. 

Only  the  DEPENDS_ON  statements  inside  this  BLOCK  group  but 
not  enclosed  in  nested  BLOCK  groups  are  of  interest  here.  Such 
DEPENDS_ON  statements  are  identified  at  line  18.  Lines  7-17 
check  the  nesting  of  DEPENDS_ON  statement  in  BLOCK  groups .  The 
cutting  of  the  edge  from  a  found  DEPENDS_ON  statement  to  its 
target  variable  is  done  in  line  19.  It3  effect  is  shown  in  the 
following  figure. 
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v  Reference  of  the  fields  in  RI 
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FIGURE  27.  Cutting  an  edge  for  a  MSCC  enclosing  a 
DEPENDS  ON  statement 


Recall  that  the  LHS  variable  of  a  DEPENDS _0N  statement 
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must  be  a  RECD  (or  a  higher  level)  node  in  a  source  file  and 
the  LHS  variables  must  be  RECD  (or  higher  level)  nodes  in 
target  files.  The  cutting  allows  the  topological  sorter, 
SCHEDULE_GRAPH ,  to  arrange  proper  computation  sequence 
according  to  the  dependency  in  the  array  graph.  The  result 
flowchart  of  the  above  array  graph  after  cutting  and  sorting  is 
as  follows. 

READ  RI 

unpacking  fields  in  RI 
computation 

packing  fields  in  RO 
WRITE  RO 

b)  Find  the  first  element  FE  in  the  given  MSCC 

This  task  is  performed  by  lines  23-31  only  when  no  current 
level  DEPENDS_ON  can  be  found.  If  the  first  statement  in  the 
current  block  is  a  BLOCK  statement,  we  have  the  following  MODEL 
specification: 

BLOCK  BLK1 ; 

BLOCK  BLK2; 
al 
a2 

END  BLK2; 

a3 

a4 

a5 

END  BLK1; 

Assertion  al,a2  are  identified  as  FE.  Where 
ai, i=l,2, 3,4. . . ,  are  assertions  numbered  according  to  their 
written  sequence. 

Taking  the  first  immediate  block  as  FE  prevents  cutting 
the  edges  inside  the  first  block,  which  will  result  in  a 
different  nesting  structure  them  the  one  specified  by  the  user. 
For  example,  if  we  have  the  above  MODEL  specification  with  the 
following  array  graph: 


Cutting  the  edge  from  al  to  a2  ( or  a2  to  al )  will  leave  us 
a  MSCC  containing  a2,a3,a4,a5. . .  .  By  using  SIMUL_BLK,  the 

following  flowchar  will  result: 

ITER  BLK2 ; 

al 

ITER  BLK1; 
a2 
a3 
a4 
as 

ENDBLK1; 

END  BLK2 ; 

This  is  not  consistent  with  the  structure  specified  by  the 

user. 

If  there  is  no  such  an  immediate  block  inside  of  a  MSCC, 
the  first  element  ( in  the  order  of  written  sequence )  must  be 
taken  as  FE . 

Lines  27-30  cut  the  backward  edges  from  the  other  elements 
in  the  MSCC  to  FE .  They  also  cut  e-e  type  edges  for  the 
elements  in  FE.  Thi3  allows  to  unravel  unnormalized  form  of 
simultaneous  equations. 

Further  unravelling  of  the  modified  MSCC  is  done  by  a 
recursive  call  to  SCHEDULE_GRAPH . 
ii)  Collect  a  list  of  variable  names  needed  for  initialization. 

Each  block  of  iterative  procedure  needs  to  initialize  all 
the  variables  that  are  LHS*  of  equations  inside  the  block.  Line 
37  performs  this  task.  Note  that  the  field  variables  indirectly 
involved  in  LHS  of  a  DEPENDS _0N  statement  must  also  be  included 
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in  the  initialization  process. 

iii)  Creating  a  block  structure  in  the  flowchart,  if  necessary. 

A  simul-block  structure  ( type  3 )  in  a  flowchart  is  created 
only  if  the  entire  MSCC  is  enclosed  in  a  block  statement 
(cur_blk)  which  bears  no  tag  ,  or  "SEXT"  tag.  The  latter  means 
that  there  is  a  DEPENDS_ON  statement  at  the  current  level. 

Note  that  the  relative  error,  iteration  limit  and  other 
block  information  contained  in  a  outer  block  statement  axe 
propagated  inward  to  the  automatically  generated  nested  block(s). 

Such  an  unravelling  process  can  effectively  find  the  nested 
structure  of  a  MSCC  involved  in  a  DSE  system  and  automatically  attach 
a  block  ( an  iterative  procedure )  to  solve  those  closely  related 
equations  in  order  to  reduce  communication  cost. 

As  an  example,  let  us  consider  the  following  MSCC  consisting  of 
six  assertions.  we  assume  that  the  user  did  not  specify  any  BLOCK 
structures . 


S-al 

i 


al( DEPENDS_ON ) 

i 

v 

T-al 


+a6<-a5->a2->a3->a4 


v 

al 


+a6  < -a5- >  a2- >  a3- >  a4 


v 

-+ 


(a) 


v 

-+ 


(b) 


FIGURE  28 .  MSCCs  in  an  array  graph 


where  ai,i=1...6,  are  assertions  named  in  their  written  sequence. 
Assertion  al  is  a  DEPENDS_ON  statement  in  (a)  but  is  an  ordinary  one 
in  (b).  S-al  and  T-al  are  source  and  taxget  (record)  variables  of  al 
respect ive ly . 

For  the  array  graph  in  Figure  28(a),  SIMUL_BLK  first  cuts  the 


edge  from  a_L  to  its  target  T-al  by  line  22.  Then  a  block  is  created 
(the  ‘'universal  block")  and  a  new  MSCC  consisting  of  only  a2,a3,a4  and 
a5  is  handed  to  be  scheduled  recursively.  Procedure  SIMUI,_BIJC  called 
again  from  SCHEDULE_GRAPH  in  scheduling  the  new  MSCC,  cuts  the  edge 
from  a5  to  a2  ( FE )  and  attaches  a  block  enclosing  a2-a5 . 


The  following  is  the  produced  flowchart: 


Block  1 
T-al 
Block  2 
a2 
a3 
a4 
a5 

End  block  2 
a6 

S-al 

al 

End  block  1 


For  the  MSCC  in  Figure  28(b),  although  it  ha3  the  same  structure 
as  the  one  in  Figure  28(a),  the  following  flowchart  i3  produced  (c.f. 
lines  32-41). 


Block  1 
al 
a2 
a3 

a4 

a5 

a6 

End  block  1 


Using  BLOCK  statements,  the  user  can  easily  create  the  flowchart 
similar  to  the  one  created  for  Figure  28(b). 


16.5  THE  PROCEDURE  "PREPARE” 


After  the  scheduling,  a  new  procedure  PREPARE  is  added  to  attach 
the  control  token  data  fields  to  be  used  in  the  termination  algorithm. 


The  procedure  PREPARE  has  two  tasks: 

i)  collect  the  target  and  source  record  names  and  corresponding 
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iteration  block  numbers  in  a  MSCC  of  a  DSE  system 
ii)  modify  the  collected  records'  lengths 

The  collected  record  names  are  stored  in  a  data  structure 
SIMU_NODES  in  the  form  of  a  list.  To  present  the  algorithm  for 
scanning  the  flowchart,  it  is  necessary  to  present  the  data  structure 
of  the  flowchart  first. 

There  are  four  kinds  of  data  nodes  in  a  flowchart . 


a)  Simple  data  or  assertion  nodes 

b)  FOR  nodes  (enclosing  a  FOR  loop) 

c)  Sublinear  block  nodes  (enclosing  a  sublinear  block) 

d)  Simultaneous  block  nodes  (enclosing  a  simultaneous  block) 

The  data  structure  description  for  these  four  kinds  of  nodes  is 
as  follows . 

DCL  1  NELMNT  BASED  (NLMNPTR), 

2  NXTNUW  PTR,  /*  POINTER  TO  NEXT  FLOWCHART  ELEMENT  */ 

2  NLMNTYPE  FIXED  BIN,  /*  =1  SIMPLE  NODE-ELEMENT  V 

2  NODES  FIXED  BIN,  /*  INDEX  IN  THE  DICTIONARY  V 

2  LVL  FIXED  BIN;  /*  LEVEL  OF  FOR  LOOP  V 

DCL  1  FELMNT  BASED  ( FLMNPTR), 

2  NXTFLMN  PTR,  /*  POINTER  TO  NEXT  FLOWCHART  ELEMENT  */ 

2  FLMNTYPE  FIXED  BIN,  /*  =2  FOR-ELEMENT  */ 

2  ELMNTLIST  PTR,  /*  POINTS  TO  A  LIST  OF  LOOP  ELEMENTS  */ 

2  FORNAME  FIXED  BIN,  /»  NAME  OF  THE  LOOP  CONTROL  VARIABLE  */ 

2  FORRANGE  FIXED  BIN,  /*  LOOP  RANGE  */ 

2  VIRINREC  bit(l);  /*  VIRTUAL  OR  PHYSICAL  */ 

DCL  1  SELMNT  BASED  ( SLMNPTR  ) , 

2  NXTSLMN  PTR,  /*  POINTER  TO  NEXT  FLOWCHART  ELEMENT  V 

2  SLMNTYPE  FIXED  BIN,  /*  =3  SIMUL  BLK,  =4  SUBLINEAR  BLK  */ 

2  SLMNLIST  PTR,  /*  POINTS  TO  LIST  OF  BLK  ELEMENTS  V 

2  SLMNLABEL  CHAR( MAXLENNAME ) ,  /*  BLOCK  NAME  FROM  USER  V 

2  SLMNLEVEL  FIXED  BIN,  /*  BLOCK  NESTING  LEVEL  V 

2  SLMNMETHOD  FIXED  BIN,  /*  SOLUTION  METHOD  CODE  V 

2  SLMNMAXITER  FLOAT  DEC,  /*  MAXIMUM  AUOWABLE  ITERATION  */ 

2  SLMNRELERROR  FLOAT  DEC,  /*  RELATIVE  ERROR  */ 

2  SLMNNAME  FIXED  BIN,  /*  ITERATION  CONTROL  VAR  NAME  */ 

2  SLMNVARS  PTR;  /*  INITIALIZATION  VARIABLE  LIST  */ 


FIGURE  29 .  Data  structures  of  a  flowchart 


A  typical  flowchart  skeleton  is  as  follows. 


( BEGIN ) 

4 - 4 

!  a  j  FILE  [open] 

4 - - - -4 

I 

i 

V 

4 - 4 

!  a  !  RE CD  [read] 

4 - 4 

I 

V  ASSR 

4 - 1-  FOR  4 - 4 

I  b  J - >1  a  I-. 

4 - 4  I  4 - 4 

j  [do  while] 

V 

4 - 4 

!  a  j  RECD  [write] 

4 - 4 

i 

t 

V 

4 - 4 

!  a  j  FILE  [close] 

4 - 4 

(END) 


SIMU  BLOCK 

4 - 4 

->  j  d  1 

4 - 4  (END  FOR  I) 

V 

+ - 4 

!  a  j  ASSR 

4 - 4 

V 

V 

4 - I 

I  a  :  ASSR 

4 . ■» 

(END  SIMU  BLOCK) 


FIGURE  30.  Representation  of  a  flowchart 


Task  ( i )  is  accomplished  by  the  following  algorithm 
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ALGORITHM  15.  FINDING  EXTERNAL  RECORD  NAMES  IN  A  MSCC 
(Procedure  Name:  GENERATE) 

Input  :  A  flowchart  generated  by  the  scheduler 
Output:  A  list  of  record  nodes  with  corresponding  iteration 
level  numbers 

Let  "flowchart"  be  the  pointer  to  the  flowchart  produced  by 
the  scheduler  ( SCHEDULE ) . 

The  initial  step  is  to  call  GENERATE ( “flowchart" ,  0 ) . 

1 .  GENERATE (  root ,  in_simu_blk )  recursive . 

2.  Do  the  following  for  each  node  in  the  flowchart  from  the  root: 

3.  If  the  node  is  a  single  node 

4.  then  if  in_simu_blk=l  & 

the  current  node  is  a  DEPENDS_ON  assertion 

6 .  then  do ; 

7 .  Put  in  SIMU_NODE  list  all  the  successors  and 

8.  predecessors  of  "node",  whose  attribute  is  "RECD" 

9.  and  save  the  current  iteration  block  number. 

10 .  end . 

11.  else  if  the  node  is  a  simultaneous  block  node 

13.  then  call  GENERATE ( next  pointer,l). 

14 .  else  call  GENERATE  ( next  pointer , in_3imu_block ) . 

15.  End.  □ 


The  data  structure  ot  SIMU_NODES  is  as  follows. 


DCL  1  SIMUNODES  BASED( S_PTR ) , 

2  NDS  FIXED  BIN,  /*  INDEX  OF  A  RE CD  NODE  IN  SYMBOL  TABLE  */ 
2  SL_NAME  FIXED  BIN,/*  ITERATION  BLOCK  (LEVEL)  NUMBER  */ 
2  NEXT  PTR;  /*  POINTS  TO  NEXT  SIMU _ NODE  V 


Task  ( ii )  is  accomplished  by  adding  10  to  the  computed  record 
lengths  of  the  records  stored  in  SIMU_N0DES.  The  physical  attachment 
of  the  token  in  the  PL/I  program  is  performed  in  code  generation 
( CODEGEN ) .  To  explain  the  attachment ,  let  XG1R  be  the  record  involved 
in  a  DEPENDS_0N  statement,  either  LHS  or  RHS.  Then  the  foilwing  data 
structure  will  appear  in  the  generated  PL/ I  program: 


1  X  FILE, 

2  XR1( *  )  RECORD, 

3  XF11 

2  XR2( * )  RECORD, 

3  XF21 

2  XG1( * )  GRP, 

3  XG1R( *  )  RECORD, 

4  XF32 

4  SITS  FLD  (PIC  ’9999999999*), 

3  XG2R( 7 )  RECORD, 

4  XF41  .  .  .  ; 

FIGURE  31.  Representation  of  a  file  structure  and 
the  patched  token  field 
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16.6  CODE  GENERATION 

16.6.1  ACQUIRING  THE  DIAMETER  OF  A  NETWORK 

As  mentioned  earlier,  the  Configurator  computes  the  diameter  of  a 
DSE  system  and  places  a  logical  name  assignment  command  in  the 
individual  JCL  program  for  each  module  in  a  DSE  system: 

$ DEFINE  MAX_D  "integer". 

Where  MAX_D  is  a  logical  name  and  "integer"  is  the  computed 
diameter.  The  value  of  MAX_D  is  then  transferred  into  individual 
modules  at  runtime. 

In  the  beginning  of  each  PL/I  program  generated  for  the  modules 

involved  in  the  DSE  system,  there  are  statements  for  acquiring  the 

diameter: 

LN_= 1 MAXD ' ; 

EQV_NAME=  *  ' ; 

STS$VALUE=SYSSTRNLOG(  LN_I1USAS ,  L_LENGTH ,  EQV_NAME ,  ,  ,  ) ; 
MAX_D=EQV_NAME ; 

FIGURE  32.  PL/I  code  for  acquiring  network  diameter 

The  acquired  diameter  is  stored  in  MAX_D  and  used  in  the 
termination  control  algorithm.  Note  that  SYS5TRNL0G  is  the  logical 
name  translation  routine  in  VMS. 

16.6.2  ATTACHMENT  OF  THE  TERMINATION  CONTROL  ALGORITHM 

The  attaching  process  is  relatively  straight forward.  So  we 
concentrate  only  on  the  functional  description  of  the  attached  program 
rather  than  the  programs  that  produce  the  attachment. 

The  current  version  of  MODEL  uses,  as  default,  the  Gauss-Seidel 
iterative  procedure  to  3olve  simultaneous  equations, 
procedure  consists  of  three  parts: 

i)  The  initialization  sequence, 

ii)  the  convergence  procedure,  and 

iii )  the  Gauss-Seidel  recalculation  loop. 


The  iterative 


Detailed  description  of  the  initialization  sequence  generation  and 
convergence  procedure  generation  cam  be  found  in  [Greenberg,  81], 

The  initialization  sequence  should  be  modified  if  the  module  is 
involved  in  a  DSE  system.  This  is  accomplished  in  the  scheduling 
stage  by  modifying  the  initialization  node  list  ( see  previous 
section).  The  termination  control  algorithm  is  attached  to  the 
recalculation  loop  which  consists  of  a)  controlled  READ  and  unpacking, 
b)  controlled  WRITE,  and  c)  token  calculation. 

The  original  recalculation  loop  has  the  following  structure: 

1.  SITER_CNVRG_1  =  'O'B; 

2.  DO  $ITER_CNTR_1  =  1  TO  50  WHILE( “SITER_CNVRG_1 ); 

3.  5 ITER_CNVRG_ 1  =  *1*B; 

4.  <list  of  recalculations > 

5.  <list  of  nested  iterative  procedures> 

6.  IF  ~SITER__CNVRG_2  THEN  $ITER_CNVRG_1  =  *0’B; 

7.  END; 

FIGURE  33.  The  recalculation  procedure  for  simultaneous  equations 

Where  $ I TER_CNVRG_ i  and  $ITER_CNTR_i  are  the  Boolean  and  integer 
control  variables  of  i-th  nesting  level  respectively.  The  number  50 
is  the  maximum  iteration  limit  ( taken  from  the  BLOCK  structure ) . 

The  attachment  of  the  termination  algorithm  is  determined  by  the 
existence  of  DEPENDS_0N  statement  in  a  simultaneous  block.  In  other 
words,  for  each  simultaneous  block  containing  DEPENDS_ON  statement s ) , 
there  is  an  extra  outer  block  -  the  termination  control  condition. 

After  attaching  the  termination  control  algorithm,  assuming  MAX_D 
is  the  maximum  diameter  acquired  from  the  JCL  statement,  the  iterative 
procedure  has  the  following  structure: 


SCNTS1=0?  SPRE_ITOSl=l?  SRLKSl='l'b? 

DO  WHILE( SPRE_ITOSl  <=  D  +  1);  /*  Termination  control  condition  */ 

1.  $ ITER_CNVRG_1  =  'O’B? 

2.  DO  $ITER_CNTR_1  =  1  TO  50 

WHILE  ( ~ 5 ITER_CNVRG_1  &  SPRE_IT0S1<=MAX_D4-1 ); 

3.  SITER_CNVRG_1=  'l'B? 

<read  label>:? 

<SRLKS  controlled  READ  action>  /*  Controlled  READ  */ 

<SRLKS  controlled  unpacking>  /*  Controlled  Unpacking  */ 

4.  <list  of  recalculations * 

5.  <list  of  nested  iterative  procedures > 

6.  IF  ~SITER_CNVRG_2  THEN  SITER_CNVRG_1  =  'O’B? 

<SRLKS  controlled  unpacking  for  control  field  SITS> 

IF  SCNTS1=0  THEN  SITOS1=0?  /*  Token  calculation  */ 

ELSE  DO? 

IF  ~$ITER_CNVRG_1  THEN  SITOS1=0; 

ELSE  IF  $PRE_IT0S  <  MIN_INP( 1 )  THEN  SlTOSl=SPRE_ITOSl  +  1? 

ELSE  SITOSl=MIN_INPl( 1 )+  1? 

END  /*  SCNTS1 >0  */? 

SPRE_IT0$1=SIT0S1? 

CALL  WRITE_IT1?  /*  Write  tokens  */ 

IF  $PRE_ITOSl  <  MAX_D  +  1 

THEN  DO?  /*  Controlled  WRITE  */ 

<output  actions  in  the  iterative  procedure> 

END  /*  OF  $CNT$1<=*  */t 

SRLKS1='0,B?  /*  Unlock  SRLKS  */ 

7.  END  /*  SITER_CNTR_1  */  ? 

END  /*  SCNTS1 <=SPRE_IT0$1  */  ? 

FIGURE  34.  The  recalculation  procedure  with  termination  control 


The  correspondence  between  the  attached  version  and  the  original 
version  caui  be  identified  by  the  statement  numbers  marked. 


The  algorithm  uses  several  control  variables,  the  correspondence 
with  the  variable  names  given  in  the  termination  algorithm  description 
i3  as  follows. 


SCNTSi  -  corresponds  to  the  index  of  the  i-th  block 

calculation  (unused,  for  debugging) 

SPRE_IT0Si  -  corresponds  to  the  i-th  block's  PRE_0  variable 

SITOSi  -  corresponds  to  the  i-th  block's  0  variable 

SRLKSi  -  the  i-th  block's  control  variable  for  controlling 

the  execution  of  the  first  READ  operation 


SRLKS i  is  used  to  disable  the  first  READ  operation  inside  of  the 
i-th  iterative  block  associated  with  a  DSE  system.  The  starting 
values  of  the  equations  must  be  from  the  INITIAL  statements. 


There  are  also  two  procedures  used  by  the  control  algorithm: 
MIN_INPi  and  WRITE_ITi  tor  each  iterative  block  i.  MIN_INPi 
corresponds  to  the  MIN  function  in  the  description  of  the  control 
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algorithm.  It  is  generated  by  the  use  of  the  SIMU_N0DES  structure. 
Assuming  FI1,FI2, . . .Pin  are  the  input  records  to  the  module  involved 
in  a  DSE  system  at  the  i-th  iterative  block,  MIN_INPi  has  the 
following  format  in  PL/I: 


MIN_INPi:PR0C( I )  RETURNS ( FIXED  BIN); 

DCL  (I,MIN_I)  FIXED  BIN; 

MIN_I=FI1 . SITS ; 

IF  FI2.SITS  <  MIN_I  THEN  MIN_I=FI2 . SITS; 


IF  Fin. SITS  <  MIN_I  THEN  MIN_I=Fln . SITS; 
RETURN(  MIN_I ) ; 

END  MIN_INPi; 


WRITE_ITi  is  a  procedure  for  sending  the  control  tokens .  It  is 
also  generated  by  using  the  SIMU_NODE  structure.  Assuming  FOl,  F02, 
. . .  FOn  are  the  output  records  involved  in  a  DES  system  at  i-th 
block.  The  WRITE_ITi  procedure  has  the  following  format: 


WRITE_ITi : PROC ; 
P01.SITS  =  SITOSi; 
F02.SITS  »  SITOSi; 


POn.SITS  =  SITOSi; 
RETURN; 

END  WRITE_ITi; 


APPENDIX  A 


EXAMPLES 

Al.  THE  RESOURCE  ALLOCATION  EXAMPLE 

This  appendix  provides  the  details  omitted  in  the  previous  parts. 
In  reading  this  appendix,  some  basic  knowledge  of  VAX-11  PL/I  and  VMS 
is  necessary  in  order  to  justify  the  correctness  of  the  implementation 
and  consistency  with  the  description  given  before. 

Al.l  THE  PHILOSOPHER  MODULE 

MWi  PROCESSOR:  version  WITH  BLOCK  STRUCTURE  ON  VAY  ii/tvi  OCTIJBP  0*.  !«S4  his -7s  52.  •? 

/  ****4»**HHHt***»*#*****#«********»»»+**«  ♦#♦****♦♦+♦«+«♦♦♦»**<  of,***"* , 

'»  °1  MODULE  SPECIFICATION  »/' 

/ 44444 444444444444444444444444444444444444444444444444444444*444444444/ 

!  MfiDULE:  PI  ■ 

2  SOURCE: ALLOC i: 

3  TftRf^T.-RFORELI: 

4 

/(♦♦H«**«t*W*H*M**tM**«**«**«**Mt*M*»H**t«*t**««*M«w; 

'*  RILE  DESCRIPTIONS:  */ 

'44444444444.44444 ’4444444444444444444444444444444444444444444444*44444, 

/ ♦  DESCRIPTION  OP  ALLOC  1  PILE  * 

/ 4444-444444444444444444444444444444444444444444 44444 4444 44444 4 4" 4*4*4* i 

4  t  Al  uv;  PI!  P  ORf.  MAIL,  /  4  P 1 1  E  T'F  ALLOf  AT  TON  4 

4  j  mc.CiA'4*  IE  RECORD.  4  INDIVIDUAL  allOCATI'iN  4. 

4  ?  PRQC.ID  IE  Fi_D l CHAR  <;>,  <4  RFC EV TNG  PROCESS  1 

4  3  CLOD- A  IE  PLD'PIC  'wnww'  i:  /♦  CLDC11'  AT  ALLOCATION  4 


/*  DESCRIPTION  op  REORFL1  PILE  */ 

P  I  R’EQPEL I  PILE  DBG  I?  MAIL-  '+  TaRf,FT  PILE  OP  RFO.REL  *< 

p  i  mpkrui  ip  RernRD.  /*  IMnj'Ji'ri w  p-fq_rel  *' 

5  >  PWT-  ID  ip  PLrifPir:  'vi,  /*  pending  pciv§pp  *• 

P  P  RQ  MR  RL  IP  FLDIPW  P).  ■'*  RPOIIEPTrRFO.  PPLPfiPE-PP'  ♦/ 

p  p  CLOD’S  IS  Pi.niPIC  ''MWKW'i,  /*  iCL'irw  AT  ppo.REL 

S  3  RES 'S'  IS  FID  (PIC  /,V!:  DEEDED  RESOURCES  SECTOR  */ 

k  >’  1 1- J>  SUBSCRIPT: 

7  TV  1  Pi  [|  (NIIM(P)): 

P 

P  ’’<1 1 II '=!F  11  =  1  THEN  1 

•P  ELSE  IF  P0.0P-PL'Il'=  PEO'  then  IVKU-l'  +  l 

S  ELSE  l (I'll-": 

9 

9  /* - PHIL  1  - - 

•5  '♦  LIFE  TIME  of  pi  */ 

9  END. REOREL 1 . M$GR ( 1 1 '  =PEC'PEL  1 . RQ  jjR _KL ' I !  ’  =  PEL  %  Il>tOi 
to 

10  PEQREL 1 . CLOD’R ( 1 1 ' = IF  U=1  THEN  TIME 

10  ELSE  ALLOC  1 . CLOD' A •  I<  1  ■'  I ! - 1 1  '-Aij.OCl.  'LOD'A'  Tc 

K»  +TIME: 


U 

11 

12 

12 

12 

12 

12 

13 
tP 

14 
11 
14 

is 


PEQPEL 1 . PROC. ID( 1 1  >=l : 


REOPEL 1 . R(5_CiR.RL ( 1 1  > = l F  11=1  THEN  REO’  4  REQUESTING  */ 

FL'PE  IF  RE0REL1.R0 J'P-FLD REO 
THEN  REL’ 

ELSE  REO’i 

REQREL1.RES'I1-J'=  (U=t  '  J=2,:  '*  '.j=Mri[i(k.S'  !  j=«Ou > v  + 1 . S i 


tVPAENl  IS  GROUP* INTERIM.  I<{ ( *" : 
4YSGEN2  IS  GROUP' END. REORELI. MSGP t* 


RANGE  ~Ap[  E 


! RANGE  no.  : 

ran4jE  definition 

JHFRE  DEFINED 

!  1  ! 

fnd  OF  "li  e 

ai  i  nr  \ , 

END  ' 

RtOREL  1 .  M'l'iF 

:  3  : 

CONSTANT  1  IMIT:C 

Kt'  lREL  \ » R~ 

RANGE  NO. 

1  j 


!  NODE  NAME 

!  DIMENSION 

♦assertion;  c. 

): 

AASSIOO 

!  IV 

AASS110 

:  IV 

AASS120 

IV 

AASS130 

:  iv 

AASS80 

■  tv 

AASRRO 

1  IV 

!*OA«E:»  ALLOC  1.) 

:  CLOCK A 

i  IV2 

:  hsga 

:  IV 

:  PPOC.ID 

:  IV 

♦fl.NAME: ( END. REORELl . > 

:  MSGS 

:  tv: 

♦Q.NAMF: ! INTERIN. ) 

!  I'd 

:  tv: 

♦U.NAME: 'REORELl. ' 

CLOCKS 

:  tv 

M%R 

tv 

proc  in 

:  tv 

RES 

:  IV 

ROjDR.RI. 

!  t  V2 

♦GLOBAL  SUBSCRIPT: 

n 

tv 

IV 


174 


mJ.iUi.'h&RT  ri'R»-!(RT 


V  TPE$  NAME 

RESCRIPT  D''N 

*VFNT 

- = = 

p; 

Mh[il  II  P  NAME 

p  ROC  ED!  IRF  HEAD  INC. 

R7 

ALi.CC  I 

RILE 

OPEN  RTi.E 

t 

T  “RAT  I  ON 

for  til  i.'NTtl  END.  <  :DE 

AASSljt 

ASSERTION 

47 

REOREli.RO  OR  PL 

FIELD  TN  RECORD  REQRELl. MSOR 

TARGET  of  ASSERTION:  AA 

:.c 

AASS.SO 

assertion 

DO 

INTERIM.  I'<1 

HELD 

tapoft  of  assertion:  a  a 

9A 

AASSRO 

ASSPRT " ON 

5i 

END.  REC'REL  1 .  msop 

SPECIAL  NAME 

-Pl.tr  T  llh  ASSr  P'*I  '.1 1‘! :  AA 

1 

TITRATION 

FOR  t’l  '.INTIL  CONS’’ ANT 

'•'4 

AASS190 

assertion 

40 

PEAP'EL  i .  RE: 

FTP!  [1  IN  RECORD  RFOP£:  1 . MSOR 

TAPOFT  OF  ASSPRT ’ON:  AA 

End'ttppattom 

for  i  12 

*1^ 

AA'SRllO 

ASSERT I ON 

40 

REC'REL  l.RROC-  ID 

sjELD  IN  RECORD  REC'REL  1 .  *SGP 

*apoft  0*  A'SER'ION:  aa 

si 

AA-SSIOO 

ASSPRT TON 

4S 

RE OPEL  i .  CLOCt  R 

FIELD  IN  RECORD  REORELl.MSr.P 

TAkOF*  of  ASSPRT ’ON:  AA 

4S 

PEoREL  1 .  MSC’R 

RE'T'RD  / N  PJLE  REC'REL' 

UPJTF  RECORD 

conditional  block 

Sllgi  ' NF AP  RANl'.F  ’S  V’A 

SS 

ALLOC  I . M$GA 

RECORD  IN  Fli  £  AL'  OC 1 

READ  RECORD 

90 

ALLOC l.PROC. ID 

FIELD  IN  RECORD  Al_LOC  1 .  MSGA 

40 

ALLOC  1  .CLIO  A 

FIELD  IN  RECORD  ALL0C1.MSOA 
RNl[i  CONDITIONAL  PLOl'f 

FOR  !NTFPI“. T«« 

END  ITFRATICiN 

POP  $T '  ” 

44 

REQRELl 

HIE 

~  .  i"|’-  w  r  ”  1  ► 

C"> 

-'t 

IYSGEN1 

i'.RmI  ip 

CD 

1YSGEN2 

lifi'CH  Ip 

PL  'T  PCfiGRAM - 


P  ■  PPnfEDHPE  r iPT I TINS i  MA I N  t : 

Da  ALLOC  IS  RECORD  SEAL  Input*. 

DCL  JFSTALLOCIS  BITH'  INIT(  ;  91: 
na  EYIST  ALLAf'IA  RJTI :  >  IN’T,  I  Pi: 

DCL  ENOFILE*ALL'‘»C!S  BP' It  IN  IT  /  vmi 
ri'  ALL  in?  1  S  fMOR'  2<’>  1  VARY  IN'.  INI*/  1: 

DCL  ALLOC LINDX  rIYED  BIN: 

AfL  tB  INTER' I  Mini  BIT/1',  iR  INTERIM!!/'  pti£T,  pin: 

If  PFOREt  1  hsc-R  S  T HAP i  1 R '  VARY IW: 

DCL  PEORELl.flBGA'.S.P  CHAP/l*': 

nCL  REQRELl  MSGR  SC  RiTcS2i  RASED 'ADDR/RF .'RE'.  '  '*C*  r-  Pi . : 
DCL  REQREL1.MBGR  IND»'  PILED  BIN: 
nCL  tU  PlYED  PIN: 

DCL  ALLOC t.NSOA.S  CHAR/ 2'"  VARYING: 

DCL  ALLOC  I  MSGA  Indy  P'i<ED  PIN: 
na  pedRElIt  pPTfiRri  seal  .tiitpiit: 

DCL  tPSTPE'TRELlT  BIT/ 1  ■  T h f t ■'  •  9.: 
fi.  .  tERRCiR-BUP  CHAR  /  27|‘>'  VAR: 

"iCL  FRRCiRF  PILE  PFCOR&  CWTR'it: 

nr l  ppRfiRF  B't  RIT'it  static  ;nit.  *  s.: 

na  iigfiT  DONE / 20)  PIT/ it: 

net  JERROR  BIT.  It  INITi  fit: 

DCL  1TMP  VAL  F;  OAT  BIN: 
na  /  !R[i  LPt.  *R  !  1  I  ABf.  : 

riECi  ARE 
1  ALLOC 1- 
:  MSOA. 

PRtY  i  D  ■'  'AAR  'll  . 

3  CLCuTAC't  PIC :'W5W«  • 
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* 


DECLARE 
1  PEAR'S  !• 

2  W, 

i  PPiT  I  [i  PIC  v  . 

3  RQ.C'R.RL ( 2 '  CHARI 3), 
i'LOCKR  PIP'RRRRRRvW/'  . 

3  RES 'S'  Rid  A': 

1 1-  ri  ARR 

1  INTER  m, 

:•  iYOTNt. 

s  r y i  r > )  pip 

2  JYRGEN2. 

ENDtREARRLi-HCGRi  2'  BIT*  l  >  : 

DCL  *11  FIXED  BIN! 

Tin  *12  FIXED  DIN: 

rif:L  (TRIIE.R0  ETTFD'  B I T 1  i  INITi  I  'D': 

ft.  <FALRF.NOT  PELE.NOT.SELECTEB*  SIT 'll  INITi  OD>: 

nn  time  RiiTLTiN: 

ON  ENDFILE*  ALLOC  IS)  BEC-IN: 

3 !  *•  r»  tft  I  : 

END: 

On  i INTCFI NEDF ILE ' ERRORF )  ERRORF  _s  IT- '.ye: 

DECLARE  Fi.lt.CNVERR  OLODAlREF  DALLE  FIXED  B I w '  ? t  > : 
fr  LARE  RMR*_RLK  OLODALREF  VALUE  FIXED  BIN' Bl t: 

ON  ERROR  BEGIN: 

IF  hNCODE < )=RMS*,RLF  THEN  GOTO  *RD_LP*: 

IF  VtERROR)  THEM  CALL  RESIGNALO: 

IF  ONCODEI i=PLI*-ONVFRR  THEN  DO: 

$ERR0R=,'0/B: 

IF  ERRORF  BIT  THEN  UR I TP  FILE' ERRORF'  FROM  .*PRROP  SHF': 

END: 

Fi.SE  PALL  RESIGNALi': 

END: 

MA  ILBOX_NA«E= ' ALLOC  1 S  _M8< ' : 

MAX.LENGTH=2C: 

STS1VALI  €=RYC:*PREMBX (  PERMANENT .  CHANNEL.  MAX  .LENGTH, .  PROT.MASF  ..MAI  Lt<0<  mMF . 
LN.ALLOC  1  3=  ■'  ALLOC  1 S ' : 

EOV.NAME=  /: 

R ,  •  *VALUF=SY$*TRNL00  '  LN.ALLOC  1 S .  l.LENGTH.  FmV.NAME  ...': 

’.F  ’"st,:*|:'J''ce';5  FD«r  pyt  skip  1  istr'^ansUtion  error  i: 

OPEN  FILE* ALLOC 1 S 1  INPUT  TITLEIEOV.NAME': 

*X*=SUBSTR(EOV.NAME. 1. L.LENGTH): 

STS*VALUE=SYS*ASSIONi*Xt, CHANNEL. . • i : 

IP  '$TS*SUCCESS  THEN  EXIST.ALL0C1S='C  B: 

*11  =0: 

*:iflT  DJNE  U ) = •"  1 '  B : 

DO  WHILE'iNOT.DONEM": 

*11  =  *11  +1 : 

IF  *11-!  then  REOREL 1 . FQ-OR.RL 1 J -  PEG': 

ELSE  IF  REQRELl.RO_CiR.RL1 1  REO'  THEN  RE0REL1.R0_0R_RL'‘2'-  "EL  •• 
n  ;f  RE OREL  1 . RO.OR  Rl< 2>-  RED": 

TF  tll=l  THEN  INTERIM. IXl'2'=l: 

ELSF  IF  RE0REL1.RO  OR  RL‘2'=  F'EO'  thFN  INTERIM. rxi ' 2 .=imteRIm. I v *  ;i  .  +  i: 
El! E  I NTER I M . !  X  l '  2  > = !  NTER I M.  I X  [  l . ; 

IF  *11=1  'HEN  DO  : 

TF  INTERIM. r xi> 2 i=l  th-n  nn: 

*B_ INTER IM*[X1=  [  E: 

*P  INTFR[M$I <1=0: 

END: 

ELSE  DO: 

*;■  1NTFR1M*IX;=  O'R: 

*R  INTERIM*:  <!-•.: 
rNTi: 

END: 

R.RF  I"  i  Interim. I x l . 2  =InTERIM.  :■■[•[■■  <  then  DA: 

*B  :NTFR!Mtr<i=  1  R: 

«R  INTERTM*I't=o: 

:  .ri: 


ELSE  DO- 

iT  !WTPS!Mi!V'-=  .'('ft: 

*R_INTERIN*I»!=i: 

END: 

FNMREGREi  l.MSfiRQirREORFl  l.RCi  OF:  RL •  2 '  =  C'EL  M!1' 

DO  *12  =1  TO  5: 

REOREL 1 .  RES !  *  1 2  >  =*  12= '.:  * !  2=2 : 

END: 

R::ORELl.RROr_!D=l: 

IF  *11=1  THEN  REOREL 1 . CLOCKR-T I  ME : 

El  SE  REOREL  1. CLOi' KR=aLUT ; iWAi  [-INTERIM.  I <1 '  l  .+INTE»!«. 

ALLOC  1 .  CLOCKA  <1-1 NTFR IM. J  X l i n  + INTER  I M .  -KtU  1  +TINE: 
REQRELlJ'SGR_INDX=i: 

SlJBSTR  f  REQREL 1  _M?GR  .SC .  REOREL  1  _MSGR_  I  NDX  *8-  ’ .  1  ♦§  l  =UNSR’EC 1  REOR'E.  1 . - 
R.  'REl  1  MOOR  INriX=REORELl  MSGP  INRK+l  : 

?II8«.TR(RF0REL1  MSQR  ?  F •  REOREL  1  NSW  'NTix.  ftt-ftEORFL1  .RO.nft  c'i  "  >  s 
REOREL  1  M?GR  !NDX=RFOREi  1  MSC.P  iN[>+<  : 

?UB?TR 1  REOREL  1  _MSOR.SC  -  REOREL  1  .MS OR _ !NBX«8-? -  *.  )*8  ■  => JMSPEC <  REOREL  1 . 
ft'  RFL 1  _ MSOR_INDX=REORELl"_M':.f'P_  IND<+ 1 A  : 

DO  *12  =1  TO  0: 

SHB?TR(RE0RFL1  MSTiR  •ftr.REORE1  1  MSOF:  'NOVttS-T.  (♦ftiriiNSFF-.ppr.pE:  « 
REOREL 1 _MSGR_ I NDX=REOREL 1 _MSOR. INDX+ I  ; 

END: 

REOREL  LMSr,R_S=?UB?TR(  REOREL  1  MSOR.S.F .  1 .  REQREL  1  _MSOR_ INDV- ! ' : 
LN_R£QREL 1  T= ' REOREL 1 T ' ; 

STStVALUE=?YS*TRNLOG(LN_REQRELlT.L_'.ENOTH,FOV_NAMF,  ..is 
IF  ASTStSUrf:ESS  THEM  PUT  SIT?  !  1ST.'  'TRANSI  AT  I  ON  ERROR'  1  >t 
*  X  *- ;JJBSTP  ( EQV.NAME .  1 ,  L.LENIjThT  : 

?TS*VALUE=?Y?*ftS?lOMI*X*. CHANNEL- • • »: 

IF  'STStSUCCESS  THEN  DO: 

PtJT  SHIP  LIST! '♦♦ERROR:  NO  CHANNEL  ASSIGNED  I  MAIL 
Ur  TE  FILE! REQREL IT )  from  ( REOREL l.MSGR.S I : 

END: 

ELSE  DO: 

S T S*VAUJE=S YS*0 1 0 ( 1  .CHANNEL.  IOt.LRITFVftLk'+IOtM.NC'U.  lO.STATiJS, . . 
ADDR  ( REOREL  1  .MSOR.S.F  i  -  LENGTH  (REOREL  1_MSC-R-Si  •  •  ■  • ) : 

IF  'STStSUCCESS  then  RUT  Sk  ip  LIS;T<  'UR I tp  010  "MSIHTESSFHL''  C  MFC  •: 
STS*VALUE=SYS*WAITFR(1>: 

STS1VALI  )E=SYS*DASSGN( CHANNEL ) : 

END: 

Ik  *B.INTERIM*IX1  THEN 
DO  : 

*X4  =  INTERIM. I < | f 2): 

*RD.ALL0C1S: : 

*R  -L=*RD_ALLOC  IS  '• 

READ  FILEIALLOCIS'  INTO  ALlOC! .MSOA.S >: 

ALLOC 1 -MSOA. I NDX= 1 : 

*FPROR.BUF=ALLOC 1 .MSOA.S: 

ALLOC 1.MSGA_S=ALlOC1.MSGA  S! •  ,20'; 

ALLOC  1 . RROC. ID=SUBSTR ( ALLOC  1 .MSOA.S • ALlOC 1 ."SOA.iND* - il>  : 

ALLOC 1 .MSOA. I NDX  =ALLOC 1 .MSG A. I NDX + 1 1  : 

*ERROR=!  B  : 

IJNSPEC I  ALLOC  1 .  CLOCK'AI  ;■ )  1  nJNSPEC  ( SIJRATR  i  ALLOC  1  .MSOA.S .  ALlOC  I  .MSC.A 
ALLOC  l.CLCO'Ai  2’  =  ALLOC  t.CLOO'  A- 21  : 

IF  tFRROR  THEN  *EPROR=  T  ft  : 

ALLCiCl  MSGA_INDX=ALLCiC  1.MSAA  IND***  : 

END: 

IF  FND*ftf OREL  1  MSGRC-I  THEN  *NhT  DONE' 1  i= B‘ 

END*REQREL1-MSGR:'  1 '  =  FNDtRFQRELl  M-IGR.ji: 

INTERIM.  IXt  IH  =  INTERIM.  7 V 1  •  2  ■ : 

REOREL l.RO  OR  Rt  in  =  RE'jF'Fli.RO  op  ri  • 
ip  tB.INTERIMtn;  THEN  ALLOC  1. CLCO-'A' !  =  ALL'Xl.C.jc  A.  '  : 

Ci  .'SE  FILE1  RE'iRELlT . : 
ft  !!PN: 


A  1.2  'HIE  R  MODULE 


MODEL  PROCESSOR:  VERSION  UITH  BLOCK  STRUCTURE  ON  VA*  11/750  OCTOBER  04.  tog* 


/♦ 

/*» 


R  MODULE  SPECIFICATION 


♦  / 
H 


t  MODULE: R: 

2  SOURCE:  REQREl: 

3  TARGET:  ALLOC, QUEUE. SIMULATION: 

4  /*  THE  FILE  QUEUE,  SIMULATION  ARE  Ffift  REPORTING  ♦/ 

4 

1  /♦  THE  MAIL  FILE  RECEIVING  MESSAGES  FROM  PHILOSOPHERS  ♦/ 

it  FILE  DESCRIPTIONS:  ♦/ 


/*  DESCRIPTION  OF  REQREL  FILE 

/HfHHHWMmHHHHHWHtHmHWHHmmimHtHmtM*/ 

4  t  REQREL  IS  FILE  ORG  IS  MAIL. 

4  2  MSGRMU)  IS  RECORD, 

4  3  PROC.IDM  TS  FIELD  (PIC'S'),  /*  ID  OF  PROCESS*/ 

4  3  RQ_OR_RLM  IS  FIELD  'CHAR  31.  /*  REQUEST =REO ■  RELEASE=REL  ♦/ 

4  3  CLOCKRH  IS  FIELD  (PIC'WWW*'),  /*TIME  OF  MESSAGE*/ 

4  3  RESM(S)  IS  FIELD  (PIC'S' *:  /* VECTOR  OF  RESOURCES*/ 

5 

5  /*  THE  LIFE  TIME  OF  R  */ 

5  END.  REQREL. MSGRM(  I )=DATE>- 'S40S23': 

A 

6  /*  THE  DISTRIBUTING  FILE  .NDING  MESSAGES  TQ  PHILOSOPHERS  ♦  / 


/*  DESCRIPTION  OF  ALLOC  FILE  */ 

ft  / 

*  l  ALLOC  IS  FILE  KEY  IS  PROC.ID  ORG  TS  POST. 

A  2  MSGAS<*>  IS  GRP./*GROUP  OF  ALLOCATION  MESSAGES*/ 

h  3  MSOAIOSRR'  IS  RECORD. /*IN0MUUAL  MESSAGE*/ 

A  4  PRCC.ID  IS  FIELD  (CHAR  11). /*ALL'3CATED  PROCESS*' 

t>  4  CLWA  IS  FJFLD  (PIC'W99W<»/»:/*TIME  OF  ALLOCATION*/ 

7 

7  /*  TiEFlNE  THE  *  OF  THE  OUTPUT  RECORDS  CAN  RE  OISTRIWlTFO  at  ’HE  ;Th  rva 

7  SIZE. ALLOC. MSGA( I >=  IF  SiZE.PR0Cd»0  THEN  i>JT_TK(  l.SI7E.PR0C<! 1 ‘  fi.se 

9 

/  o*******************************************************************  / 

/*  DESCRIPTION  OF  SI«ULATI  FILE  *>' 

S  1  SIMULATION  IS  FILE. 

9  2  HOI  IS  RECORD. 

S  3  HOF!  IS  FI ELD (CHAR  125). 

ft  2  HD2  IS  RECORD- 


3  MTiF2  IS  FT ELD (THAR  12 
MB'*  I0:  RECORD- 
•:  HDF3  I?  FIELD  (CHAR  1 25>  - 
FVFNT  i  ♦  *  I<*  RECORD, 

G  RFOtiERT  IS  GRP. 

4  PROP  I  DM  IS  FIELD*  CHAR'  4*. 
4  FILLER  1  IS  FIELD* CHAR  H. 
4  RO  rw.RLM  is  FI ELD (CHAR  3*. 
4  FIl  I  ER2  15  FI  ELD  (CHAR  n. 
4  RFSM(S)  IS  FIELD(PIC 
4  FILLERS  IS  FIELDICHAR  1 I. 
4  rinfYRM  is  F I  ELD  ( P T  C  DM 
4  FILLER*  IS  FIELO'CHAR  2'. 
•:  ALLOCATION**'  IS  GRP, 

4  fillers  tS  field* CHAR  t'- 
4  PRir.IDA  IS  FIELD d'HAR  4i. 
4  FILLERS  IS  FiELEHfWAR  t». 
4  n.iYKA  TS  FI  ELD 'P!'":  "R(  t 


S I MIJL  AT  I  ON ,  HITF  l ='  REQUEST 

SIM!JLATI0N.HDF2='P-ID  R/L  RE'SRC 


SIMULATION. HBF3='= 


P.ID  "THE 
P.ID  time 

p.ID  ttme  ! 


ALLOC at I 


(2  *  FILLER 1  -  FILLERS- FILLER3. FILLER*. FILLERS. FILLERS  <  =  •: 

13  SIMULATION.  PROC.IDM  =REQREL.  PROC.IOM: 

14  SIMULATION. RESM  =REOREL.SESM: 

15  S I HIJLAT I  ON .  CLCO'RM  =REOREL.  CLOCKRM: 

IS  SIMI.il.ATION.PROr.IDA  =SUBSTR(ALUX.PRTif  !D.S.t»: 

17  SIMULATION.  CLQCKA  =ALLOC.CLOCKA; 

13 

13  /*  the  OUEUE  FILE.  DEFINED  AS  TARGET  TQ  CHECK  THE  R  ♦/ 

/♦  DESCRIPTION  OF  QUEUE  FILE  ♦  / 


13  1  QUEUE  IS  FILE, 

13  2  PROO<«'  IS  RECORD.  /*  RECORDING  THE  HISTORY  OF  THE  XE'IE  *■' 

13  3  PR0C(0:RR)  IS  GROUP.  /♦  PROCESS  QUEUE  FOR  EACH  I  */ 

!:?  4  PROC.ID  IS  FIELD  'PIC'S''./*  to  ijF  PROCESS  ♦  / 

13  4  in.IT  IS  FIELD  (PIC'RWWRR'i. 

13  '♦INDEX  OF  PROCESS  IN  PRECEEDINO  QUEUE*/ 

13  4  Qi.rr.IT  is  FIELD  (PIC'S' P'*  INDEX  Cf  PROCESS  TN  ALLOCATIONS*' 

13  *  RES(5)  IS  GROi.iP.  '♦  RESOURCE  VECTOR  ♦/ 

13  5  CLAIM  IS  FIELD  (PIC'S' '<• '*MAXINJM  RESOURCES  CLAIMED  BY  PROCESS*/ 

13  5  SUN.REQ  IS  FIELD  (PIC'R'*./*StJMR  OF  REQUESTS  FOP  RESOURCES  IN 

13  AiJEiJE  iWiFR  */ 

13  5  SAT  IS  FIELI'  'BITMH; 'HjHETHEO  RESOURCES  ARE  AVAILABLE  r0. 

IS  SATISFY  CLAIMS  IN  ORDER  OF  RESOURCES* ' 

IS  1  RES.LIMIT  IS  GROUP- 

IS  2  NUM.RES15T  IS  FIELD  IPIC'SM: /♦m.lMBER  OF  RESOIJRCES  IN  SYSTEM  THAT 

20  MAY  RE  ALLOCATED*' 

20  /*data  PARAMETERS*/ 

20  *  I,.j,K)  ARE  SUBSCRIPTS:/*!:  SUBSCRIPT  OF  REQUEST  /RELEASE  MESSAGES: 

21  J:  SUBSCRIPT  OF  RESOURCES: 

21  k':  SUBSCRIPT  OR  PROCESSES  IN  OI0IE.  */ 

21 

21  '♦  DEFINE  SIZE  OF  QUEUE.  ♦' 

21  SIZE.PPX(I)=(F  i=l 

21  then  l 

21  ELSE  IF  PEQREL.RQjOR-RLM(r'='REL 

21  THEN  SnE.PPOCi  1-1  )-l 

21  ELSE  SIZE.PROC(I-P*t: 
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oo 

00 


70 

23 

23 

23 

23 

23 

24 
24 
24 
24 
24 
24 
24 
24 
24 
24 

24 

25 
25 
25 

25 

25 

25 

25 

25 

25 


26 

26 

26 


27 


07 

Ut 

OT 

23 

28 

28 

23 

28 

28 

29 

79 

2* 

29 

29 

29 

-9 

29 

30 
30 
2A 

30 

31 

31 

32 

33 

34 


/♦  DEFINE  the  ns IMBEP  of  flVAILA&EL  RESOURCES  IN  THE  SYSTEM.  */ 
W_W_RES(J>=H  ■'♦ONE  FORK  IN  EACH  POSITION*' 

/*  OEFINE  THE  QUEUE  CONTENTS:  ♦/ 

QU0IE.PROC.ID(I>K)=  IF  RE9REL.RQ.0R.RLMdt='REQ  %  'K=SIZE.PROCd" 
then  REQREL.PROC.lDMd)  /*  PUSH  */ 

ELSE  QUEUE.PROC-IDd-MlUXd-Kl':  /*  COPY  */ 

/*  DEFINE  THE  INDEX  FOR  VARIABLELY  SIZED  QUELIE.  */ 

IN.IXd.K's  IF  REQREL. RQ.OR-RLIK I > s'REQ' 

THEN  K 

q.SE  IF  REQREL. P&OC.IDM' I t'^JEUE. PROC. ID< t-l.n 
THEN  IF  K=l 
THEN  1 

ELSE  IN.IXd.K-tM 

F!  SE  IF  K=l  I*  WIST  8E  PEL-  THE  0  SIZE-1  «JT  RRE.INX+l 
THEN  2 

ELSE  IN_IYd.K-l)*2: 

/♦  DEFINE  THE  OLITPI.it  INDIRECT  INDEX  */ 
ni.IT.! X d . K)=IF  REQREL .  RQ.CiR.RLH <  I  > ='REL ' 

THEN  IF  SATd.K,5>«(  ASATd-MN.IXd.l0.5» 

THEN  IF  K=t 
THEN  1 

ELSE  oirr.iXd-K-n+t 
ELSE  IF  K=t 
THEN  0 

ELSE  OUT.lXd-K-n 
ELSE  IF  K=SIZE.PR0Cdi*(SATd.K.5l 
THEN  1 
ELSE  0: 

/*  DEFINE  CALIM  FOR  EACH  PROCESS.  */ 

CLAIMd.K.J>=  IF  REQREL. RQ.OR.PLMd^'REQ'  i  'K=SIZE.PROCd>i 
THEN  REQREL. RE SM d -J l 
ELSE  CLAIMd-MN.IXd.K>..j>: 

SlJM.REQd.K,J)=  IF  *=t 

THEN  QUEUE. CLAIMd-K-J) 

ELSE  QUEUE .CLAIMd. K-.l‘  ♦SUM.REQ d . K- 1 . J t s 

/«  TEST  VARIABLE  FOR  DETERMINING  the  ALLOWABLE  RESOURCES.  */ 
SATd.K,J)=IF  ,1=1 

THEN  (SUM-PEQd.K,JK=NUM-RES(Jt  :  QUEUE .  CL  A I  m  d  •  K .  ,n  =0 1 
ELSE  SATd-K-J-M  * 

I SUM.REQ d . KL J) <=NUM_RES ( J t  !  OUEL£.CLAtMd.K-jt=Ol; 


/*  EQUATIONS  FOR  VARIABLES  IN  file  ALLOCA  */ 

i*  DEFINE  the  MAILBOX  ADDRESS  *> 

ALLCC.PROCJDd.OlJT.IXd.Kn= 

IF  IK=1  *  DIJT  IXd. K)  =  d  I'KSl'MOI.rr.IXd.Kf  aiT.IX'  I- K-l  t  < 
THEN  CHPTRLB < '  ALLOT ■■ !  I  LEFT,  HOUSE.  PROC. IDd  -  K » '■ : : ' S.MBX  ’ ' : 
/♦  DEFINE  ALLOCATION  time  */ 

ALLOC. CLOC'KA 1 1 . OUT. I x d •  k ) t=!F  (K'=t  WUT.IX'I .Kt=n 

i  ik>i  \  mrr  ixa.mm/T  rxd-K-nt 
THEN  REQREL  .CLXKRMI 1 1 : 

3 IHJL AT I . RQ.OR_RL=REQREL . RQ.OR.RL : 

4YSC-EN1  IS  GROUP' END. REQREL. MSORMI *  I  > : 

4VSGEN2  1 3  GROUP  'SIZE.  QUEUE ,  PROC  <  *  1 1 : 

IYSGEN3  IS  0R0UP<SI7E.ALLX.MS0A<tn: 


FLOWCHART  RFPriPT 


Of 

*  NAME 

R 

7A 

REQREL 

56 

AASS90 

S4 

SIMIATI.HDF1 

83 

A 

SIMILATI.HD1 

1 1 

45 

AASS220 

105 

INTERIM. NUM.RES 

10« 

INTERIM.RES.LIMl 

x> 

0 ASS 110 

31 

AASSIOO 

86 

SIMULATI.HDF2 

85 

SIMLATI.HD2 

fts 

SIMULATI. HDF3 

87 

A 

SIMl.LATI.H03 

\  ) 

54 

AASS50 

ION 

END. REQREL. MSGRM 

77 

REQREL. MSGRM 

78 

REQREL. PROC.IDM 

3'.i 

AASS130 

PI 

SIMULATI. PROC.IDM 

70 

REQREL.RQ_OR.RL 

!Q9 

AASS310 

PS 

3IMLATI.PQ_0R.ftL 

44 

AASS210 

107 

0 

47 

SIZE.  QUEUE. PROC 

AAS3240 

70 

QUEUE.IN.lt 

46 

AASS230 

69 

QUEUE. PROC-ID 

REQREL. CLOCKRM 

41 

AASS150 

97 

0 

81 

SI  ML  AT  I.  CLOCKRM 

REQREL. RESM 

40 

AASS140 

95 

0 

49 

SIMULATI. RESM 

AASS260 

73 

queue. claim 

50 

AASS270 

74 

QUEUE. SUM.RE9 

51 

AASS280 

75 

QUEUE. SAT 

72 

QUEUE. RES 

0 


4ft 

AASS250 

71 

QUEUE. OUT.IX 

53 

AASS300 

5? 

AASS290 

68 

QUEUE.  PROC 

V. 

AASS70 

.108 

SIZE. ALLOC. MSG A 

61 

ALLOC.  aOCKA 

43 

AASS170 

103 

SIMULATI. CLOCKA 

DESCRIPTION 
MODU.E  NAME 
FILE 

ASSERTION 

FIELD  IN  RECORD  SINI.ii_ATI.HD1 

RECORD  IN  FILE  SIMULATI 

ITERATION 

ASSERTION 

FIELD 

END  ITERATION 
GROUP 
ASSERTION 
ASSERTION 

FIELD  IN  RECORD  SIW.1ATT.HD2 

RECORD  IN  FILE  SIMLA! I 

FIE.D  IN  RECORD  IMLATI.HD3 

RECORD  TN  FIL_  ilMLATI 

iteration 

ASSERTION 

SPECIAL  NAME 

RECORD  IN  FILE  REQREL 

FIELD  IN  RECORD  REQREL.  MSGRM 

ASSERTION 

FIELD  'N  RECORD  SI  ML  ATT.  EVENT 
FIELD  IN  RECORD  REQREL. MSGRM 
ASSERTION 

FIELD  IN  RECORD  SIMLATI.  EVENT 

ASSERTION 

SPECIAL  NAME 

iteration 

ASSERTION 

FIELD  IN  RECORD  QUEUE. PROC.O 
ASSERTION 

FIELD  IN  RECORD  QUEUE. PROC.O 
END  ITERATION 

FIELD  IN  RECORD  REQREL. MSGRM 
ASSERTION 

FIELD  IN  RECORD  SIMLATT. EVENT 
ITERATION 

FIELD  IN  RECORD  REQREL. HSGRH 
ASSERTION 

FIELD  IN  RECORD  SIMLA! I, EVENT 

ITERATION 

ASSERTION 

FIELD  IN  RECORD  QUEUE. PROC.O 
ASSERTION 

FIELD  IN  RECORD  QUEUE, PROC.O 
ASSERTION 

FIELD  IN  RECORD  QUEUE. PROC.O 

ORrop  IN  RECORD  QUEUE. PROP  Q 

END  ITERATION 

END  ITERATION 

ITERATION 

AccroTIf#! 

FIELD  TN  RECORD  QUEUE. PBQC.Q 

ASSERTION 

assertion 

GROUP  IN  RFCORD  r.lipiE.PPfT  0 
FND  ITERATICiN 


ASSERTION 
SPECIAL  NAME 
ITERATION 

FIELD  IN  RECORD  ALLOC.  «SC-A 
ASSERTION 

FIELD  ;N  BE"  ORD  c  I  NIL  AT  I,  EVENT 


EVENT 

PROCEDURE  HEADING 
OPEN  FILE 

TARGE’  OF  ASSERTION:  AASS^O 
WRITE  RECORD 

FOR  til  UNTIL  CONSTANT  lIMITB 

TAROFT  OF  ASSERTION:  AASS220 
FOP  *11 


T AROFT  OF  ASSERTION:  AASSIOO 
WRITE  s'F'ORD 

TAROFT  OF  ASSERTION:  AASSll'i 
WRITE  RFCORD 

FO0  *11  UNTIL  END. I  SPECIFIED 

TAROFT  OF  ASSERTICiN:  AASSSO 
READ  RECORD 


target  OF  ASSERTION:  AASS130 


TARGET  of  ASSERTION:  AASS31Q 

TARGET  OP  ASSERTION:  AASS2M 
FOR  *12  until  SIZE.*  'SPECIFIED 

TARGET  OF  ASSERTION:  M.SS240 

TARGET  OF  ASSERTION:  AASS230 
FOR  *12 


taroet  of  ASSERTION:  AASS150 
FOP  *12  UNTIL  CONSTANT  UNIT'S 


TARGET  OF  ASSERTION:  AASS140 
FOR  *1?  UNTIL  SITE. *  SPECIFIED 

target  of  ASSERTICiN:  AASS260 

TARGET  OF  ASSERTION:  AASS270 

-ARGET  OF  ASSERTION:  AASS2S0 

FOR  *13 
FOR  *12 

FOR  *12  UNTIL  SITE.i  specified 
target  of  ASSERTION:  AASS250 


FOR  $12 


TARGET  OF  ASSERTION:  AAS'STO 
FOR  *12  UNTIL  SITE. *  SPECIFIED 
TARGET  OF  ASSERTION:  SASSSOO 

TARGET  OF  ASSERTION:  AASSI'0 


target  of  ASSERTION:  aars;-*;. 


GO  ALLOC. PROC- ID  PI ELD  TM  RECORD  ALLOC. MSGA 


it ' 

AAljS l nO 

ASSERTION 

<01 

SIWJLATI. RROC.IDA 

FIELO  TN  RFCriRn  SIWHJ1TT. EVENT 

T ARC, FT  CF  ASSFRTMN:  AASSl AO 

S9 

ALLOC. MSGA 

RECORD  IN  RLE  ALLOC 

WRITE  RECORD 

04 

AASSl 20 AB 

ASSERTION 

100 

SIWJLATI. FILLERS 

PI ELD  IN  RECORD  SIWJLATI. EVENT 

TARGE7  op  ASSERTION:  AASSl 20 AB 

00 

AASS120 

ASSER'ION 

102 

SIWJLATI. FILLER* 

PIELD  IN  RECORD  SIWJ  ATI. EVENT 

TARGET  OT  ASSERTION:  AASS12C' 

99 

SIWJLATI.  ALLOCATI 

GROUP  TN  RECORD  SIWJLATI. EVENT 
END  ITERATION 

PCS  $12 

Sft 

ALLOC.  MSGAS 

GROUP  IN  PILE  ALLOC 

6? 

QUEUE. PROC.Q 

RECORD  IN  PILE  QUEUE 

WRITE  RECORD 

OS 

AASS120AF 

ASSERTION 

99 

SIWJLATI.  FILLER1 

FiELD  TN  RECORD  SIWJLATI . EVENT 

TARGET  OF  ASSERTION:  AASS 1 20A” 

07 

AASS120AE 

ASSERTION 

94 

SIWJLATI.  FILLER2 

FIELD  TN  RECORD  SIWJLATI. EVENT 

TARGET  Ci"  ASSERTION:  AASSl 20AE 

OA 

AASS120AD 

ASSERTION 

9.4 

SIWJLATI .PILlPRp 

FIELD  in  RECORD  SIWJLATI. EVENT 

TARGET  CP  ASSERTION:  AASSl 2GAD 

OS 

AASS120AC 

ASSERTION 

9;0 

SIWJLATI. FILLERS 

PIELD  TN  RECORD  SIWILATT.PVPNT 

TARGET  CiF  ASSERTION:  AAS:‘20AC 

90 

SIWJLATI.  RCuljFOT 

GROUP  IN  RECORD  SIWJLATI .EVENT 

ft9 

SIWJLATI.  EVENT 

RFCOFTi  TN  Fli  F  F 1 1*« i:_ AT I 

END  ITERATION 

WRITE  R'E'CRT, 

POR  til 

no 

tYSGENt 

c,RmiP 

tu 

1YSGEN2 

•GROUP 

112 

iYSGENS 

iiRniip 

C7 

Al  i  Of 

PILE 

close  PILE 

■S*  QUEUE  PILE 

02  OWL  AT  I  PILE 


CLOSE  PILE 
CLOSE  PILE 


—  PL;  I  PROGRAM  — 


R:  PROCEDURE  OPTIONS(MAIN): 
nCL  RE9RELS  RECORD  SECL  INPUT: 
nCL  «FSTREC'PELS  BIT f  1 )  INITfM'B): 

OCL  EHISTJJEflRELS  BIT <  t >  INIT(M'B): 

OCL  ENOFIlEffESNELS  BITM 5  INITf'rt'B): 

OCL  RE0REL.S  CHARMS)  VARYING  INITf"): 

OCL  REOREL-INOX  FIXED  BIN! 

OCL  SIMULATI.HBl.S  CHAW  125*  VARYING: 

OCL  SIMt.lLATI_HOl.S-F  CHARM  25): 

OCL  S!MiJLATI_HDLSC  B1TM0Q0)  BASED < ADDR < S I MIJLAT I _H[i  1_:_F ’  ■ : 
na  SWLATI-HBLINBX  FIXED  BIN: 

OCL  SI  MIJLAT  t_HD2_S  CHARM25)  VARYING: 

OCL  SIMULATI.H02.S-F  CHARM  25  *J 

on  SIM!#  ATI  HTi2  sr  RITMOVO  RASEO < ADr|R t SIMl  1ATI  HD 2  S  P>  > s 
OCL  SIMIJLATI.HD2.INDX  FIXED  BIN: 

OCL  SIMULATI.H03.S  CHARM25'  VARYING: 

OCL  SIMULATI_HD3.S.F  CHARI  125): 

OCL  SIMULATI.H03.SC  BIT (1000)  BASED ( ADDR ( S I MULAT I .H03.S : 

OCL  SIMI.LATI_HD3.IN0X  FIXED  BIN; 

OCL  REQREL_MSGRM_S  CHARM?)  VARYING: 

OCL  PEQREL.MSGRM.INOX  FIXED  BIN: 

OCL  ALLOC.MSGA.S  CHAR ( 20 '  VARYING: 

OCL  ALLOC.MSGA.S_F  CHAR (20): 

OCL  ALLOC_NSGA_$C  BITM60'  BASED  (ADDR  ( ALLQC_MSGA_S_F ' ' : 

OCL  ALLOC .MSGA.INDX  FIXED  BIN: 

net  QUEUE.PROC.Q_S  CHAR (2574)  VARYING: 

Da  OUEUE-FROC_Q_S_F  CHAR(2574): 

OCL  «!UEUE_PROC-(t_SC  BIT(205?2)  RASE0<6DDR'Qt.€UE_Pft0C_Q.S_F'): 

OCL  QUEUE.PROC.Q.INBX  FIXED  BIN: 

OCL  SIMULA!! .EVENT .S  CHART  19 U)  VARYING) 

OCL  S I  MIJLAT  I  _EVENT_S_F  CHARI  1911): 

OCL  SIMt.LATLEVENT.SC  B1TM5288)  8ASED(ADDR($IMULATl_EVENT_3_Fl ) 
DCL  SIMl.LATI_EVENT.INDX  FIXED  BIN: 

OCL  iH.QIJ0JE4PROC.IO(2)  FIXED  BIN; 

CALL  «INITUIN(tU_ffl_ejEWOC.ID. 2) ) 

OCL  «_QUEUEISATf2)  FIXED  BIN! 

CALL  4lNlTWIN«H_0l.e.€*SAT,2): 

OCL  *W_0UEUE$CLAIM(2 )  FIXED  BIN: 

CALL  *INlTWIN(*W_a€UE*CLAIM, 2) : 

OCL  ALLOCT  RECORD  SECL  OUTPUT; 

OCL  $FSTAI.L(XT  BIT(l)  INIT('l'B): 
rCL  QUEUET  RECORD  SEC-L  OUTPUT: 

OCL  tfSTQUEUT  BITM!  INITfM'B): 
r<L  SI  MIL  AT  IT  RECORD  SECL  OUTPUT; 

DCL  fFSTSIMt.LATIT  BITM)  INIT(M'B): 

OCL  4ERR0R.BUF  CHAR (270)  VAR: 

TiCL  SPRORF  FILE  RECORD  OUTPUT: 

OCL  ERRORF.BIT  BITM)  STATIC  lNlTt'l'B): 

OCL  *N0T_B0NE<20)  BITM): 

OCL  tERROR  BITM)  INIT('O'B): 

OCL  4TMP.VAL  FLCtAT  BIN; 

0C_  t*RO_LP$.*R-L,  LABEL: 

DECLARE 

1  ALLOC- 

2  MSGAS, 

3  MSGA, 

4  PROC.IOtW  CHARM I). 

4  aoCFAt??'  Pir'wwww': 


4  PR0C_IDI2,o°i  Pir-'O'. 

4  IN  IXi°°) 

4  OUT.IXW?  PIC'0", 

4  RES, 

5  CLA!M(2,PP.5>  PIC'0'. 

5  SUM_REQ(°9.5)  PIC'0'. 

5  SAT(2,0°,5'  BIT(l): 

DECLARE 

1  REGREL- 

2  MSfiRH. 

5  PRiT.IIH  PIC'°'. 

3  RO.OR.RL  CHARTS’- 
3  rCnrxRM  Pir-'RwoRwo', 

S  PEc-«  PIT  'v  : 

DECLARE 

!  sJWLATI, 

2  HD  I- 

3  HDRl  char f 125), 

2  HD2- 

3  N0F2  CHAR (125)- 

2  HD3- 

3  HOPS  CHARI  125). 

2  EVENT, 

s  REVEST. 

4  PRCC-IDH  CHARI4). 

4  PILLER1  CHARI  1). 

4  RO-OR-PL  CHARI?). 

4  PILLER2  CHARI t). 

4  RESNI51  PIC'0'- 

4  FILLER3  CHARI  1). 

4  CLOCKRM  PIC'B<12)°'. 

4  F1LLER4  CHARI 2). 

3  ALLOC ATI. 

4  CILLER5I°°)  CHARI  1). 

4  PROC_IDA(°°l  CHARI41. 

4  PILLER6(°0'  CHARI  1). 

4  CLOCKAI00'  PIC'BI 12)v  s 
DECLARE 

1  INTFRIH. 

2  RES.LIMI. 

3  NUH.RESI5)  PIC'0'. 

2  4VSGEN1, 

3  END$REQREl_MSGRM ( 2 1  BIT  f 1 )  . 

'  IYSGEN2. 

3  3 I 7E4QUEUE_PR0C ! 2 )  CIXED  BIN  . 

2  4Y3GEN3, 

3  5I7E4ALLOC.NSGA  FIXED  BIN  : 

XL  $11  FIXED  BIN: 

XL  $12  FIXED  BIN; 

XL  $13  FIXED  BIN: 

XL  'TRUE. SELECTED)  BIT'1)  INITi'l'Sl: 

XL  I  FALSE ,  N0T.5ELE .  NOT.SELECTED )  BIT'  1 )  INITt'OB': 
XL  3UBSTR  BIJILTIN: 

XL  DATE  8UILTIN: 

LEFT.j:  PRQCUO  RETURNS  I  CHARI  101  VAR):  /♦  $START$  */ 
CONVERT  A  NUMBER  INTO  A  VARIABLE  LENGTH  STRING  */ 
XL  U,jt  FIXED  BIN: 

XL  ST  CHAR 1 20)  VAR: 
del  answer  chad  10)  var: 

ST=*: 

,I=VERIFYIST,'  O'l: 

IF  J=0  THEN  ST='0- : 

ELSE  ST=SIJBSTR(ST.J): 
an=wer=st: 
ret'jrnlanswer'; 

END  LEFT.J:  /«  |EN0$  */ 


~  194  - 


KfiTATE:  PROC  EDURE  <  W I  N_VEC  >  LEN  '• :  /*  tv  ART  i  ».• 
nCL  WIN.VEC!*'  FIXED  BIN: 

HCL  <  MEN. TEMP)  fjxED  BIN; 

TEMRryiN.VECd); 

Til  I  =  2  TO  LEN! 

ulN_VFf:iI-l)=WIN.VEC!I): 

END: 

4TN_VEC  f  LEN>  =TEMP; 

END  IROTATE:  /*  *ENBt  ♦/ 

tiNITMIN:  PROCEDURE(WIN.VEC.LEN):  tSTARTt  */ 

OCL  WIN.VEC!*)  PIXED  BIN: 

OCL  (MEN)  FIXED  BIN; 

DO  1=1  to  len; 

WIN.VEC: !>=!! 
cnp; 

FND  tINTTWIN:  '*  tENO*  ♦ 

i'HF'TR!  B:  PRfOiNAME'  RETURNS  1  CHAR <  02'  VAR):  *  txTARTt  */ 
net  NAME  CHARI*': 

DT.L  RESULT  CHAR <32)  VAR: 
net  :  I  •  LEN )  FIXED  BIN: 

Tp  NAME=''  THEN  RETURN!  '): 

LEN=LENGTH(NAME’: 

/♦THIS  PROCEDURE  CHOPS  off  the  TRAILING  BLANK'S  •' CHTRLB >  >jF  A 
LENGTH  'NAME'  AND  RETURNS  A  VARIABLE  LENGTH  ONE*/ 

TO  I=LEN  TO  l  BY  -1  WHILE < SIJBSTR ( NAME •  M '  ='  '): 

END: 

RESULT-SUBSTRfNAME. 1 • I ) : 

RETURN!  RESULT): 

ojn  chptri_B5  •■’*  tENDt  */ 

ON  ENDFILE(REORELS)  BEGIN: 
ioto  tF'.L: 

END: 


ON  UNDEFINEDFILE(ERRORF)  ERRORF.BIT-'O'B: 

DECLARE  PLIt.CNVERR  OLOBALREF  VALLE  FIXED  BIN(3l>: 

HECLARE  RMSt.RLK  OLOBALREF  VALLE  FIXED  BIN! 3D: 

ON  ERROR  BEGIN: 

TF  ONCODEf 1=RMS«.RLK  THEN  GOTO  tRO.LPC 
IF  VtERROR)  THEN  CALL  RESIGNAL! 

IF  ONCODEO=PLIt.CNVERR  THEN  DO: 

SFRRGR^'O'&J 

IF  ERRORF.BIT  THEN  WRITE  FILE(ERRORF)  FROM  (tERROR.BLiF): 

END: 

ELSE  CALL  RESIGNAL! ): 

END: 

MA I LBOX .NAME= ' REQRELS.MBX ' : 

MAX.LEN6TH=1R: 

STStVALL€=SYS*CREMBX ( PERMANENT, CHANNEL , MAX .LENGTH. , PROT.MASX 
LN.REQRELS-'REQRELS ' : 

E0V.NAME=-' 

ST StVALLE=SYS$TRNLCO  I  LN.REORELS  - 1 _ LENGTH .  EQV.NAME  •  - , ) : 

if  'ststsuccess  then  put  skip  1 ist< "translation  error'): 

OPEN  FILE(REORELS)  INPUT  TITLE<FGV_NAME': 
tX  t=SIJ6STR  ( EQV.NAME ,  1 ,  L  .LENGTH ) : 

STSiVAUJE=SYS»SSIGN(*X*.  CHANNEL, ,  • t : 

IF  'STS1SUCCESS  TURN  EXlST.REQRELS='0'B: 

SINULATI.HDFl*'  REQUEST 

SIMULATI_HDl.INDX=l: 

SUBSTR  ( S I MUL  AT  I  _HD  1  _S_F ,  S I MUL  AT  I  _HD  1  _  I NDX  D  25 '  =S  I MIJL  AT  I , HDF | 
SINJLAT1_H0UN0X=SIMULATI_HDUNDX+125  : 
SIMIJLATI.HOl_S=SUBSTR(SIMi:LATI.HDl.S_F.l,SIf*.EATI.HDI-INDX-U 
WRITE  FILE’SIMLLATITt  FROM  ISIMULATI.HD1.S': 

00  *11  =1  TO  ■5: 

INTERIM.  M.lM.RES(«ID=t: 

END: 


SIMUIATI.HDF2-'P_ID  R/L  RESRC  TIME 
:  DIME  -D  'P.ID  TIME': 


PTVFTi 


■  MAILBOX .NAMF! 


ALLOCATION': 


R.iD  time 


3  I MIJLAT I  _HD2_  I  NDX= t : 

:.i.fBSTR  ( 5 1 MULAT I  _HD2_S_F  •  SIMULflT  I  _HD2_  I NBX . I 25 i =S I MULAT I .  HDF 2  : 

■5 1  MtJLAT  I  _HD2_  I  NDX=S  I  m.M_AT  I  _HD2_  MDX + 1 25  : 

SIMIJIAT I  .HD2_S=SU6$TR  <  SIMULATI  .HB2.S.F  •  1  ■  SIMULATI .HD2.INDX  - 1 ' 

WE  FTLEiSIMlJLATlT)  FROM  < SIWXATI _HD2_S <  s 
SIMULATI_HB3_INDX=t ' 

SUBSTR  <  5 I MULAT I  .H03.3.F  •  S I MULAT I  _HD3_  I NOX . 1 25  *  =S I MIJLAT  I .  HQF3  s 
'3! MIJLAT  I  .HD3.  INOX=S IMUL ATI  _HD3_  INDV+ !  25  : 

■3 1  MULAT  I  _H03  _-E-=SUBSTR  ( S I WULAT  T  _HD3_S_F  *  i  •  S!  WJLAT I  _HD3_  1 NDX  - 1  > : 

WE  FILEi 31MIJLATIT)  FROM  (SIMI.ILATl.HD3 .31: 
ill  =0! 

iNOTJTiNEm-  1  9: 

DO  WHILE  •'  iMDT_DOi\E !  1 ' ! : 
til  =  ill  +t: 

ENOfREOREL-MSORM  <  2  *  =OATE>= •'  840923 '  s 
SRD.RE'DRELS: : 

*R _ -iRO.REQRELS: 

READ  FILEfREQRELS'  INTO  (REQREL.MSGRM.S): 

REQREL-MSGRM. I NOX= 1 : 

*ERROR.BUF =REQPEL_MSGRM_S : 

REC!REL-M$GRM_S=R£QREL_M$GRM_$  !  1  copy  r  M9»: 
iERROR='l/R  s 

UNSPEC  ( REQREL. PROC. I DM )  =UN$PEC ( SUBSTR  ( REOREL.MSORM.S ,  REQREL-MSGRM. INOX  •  1 » '■  ! 
REQREL. PROC. I DM  =  REQREL.PROC.IDM  : 

IF  tERROR  THEN  *ERR0R='0"R  : 

REQREL-MSGRM. INBX=REQREL_MSGRM_ INDX+ 1  : 

S I  .HJLAT I .  PROC.  I  DM=REQREL .  RROC.IDM: 

F'EQREL .  RG_OR_RL=SUBSTR  <  REQREL.MSGRM.S  -  REWEL.MSGRM.INDX  .jit 
REQREL-MSGRM.  INDXWEQREL  J1SGRM.  INOX+3  : 

S I  MULAT  I .  RQ.OR_RL=REOREL .  RQ.QR.RL ; 

IF  *11=1  THEN  S I ZEtGUEUE.PROC <21=1; 

ELSE  IF  REQREL . RCLOR_RL= 'REL '  THEM  S I ZEtOUEUE.PROC ( 2 ' =SI ZEiOUEUE.PRCC 1 1 H : 
ELSE  SIZEiQUEl.€J>ROC(2)=SIZE*QUOJE_PROC:(  1  >*l« 

00  *12  =1  TO  SIZE*QUEUE_PR0C(2): 

IF  REQREL. RQ_OR.RL='REQ'  THEN  QUEUE. IN_IX(*I2>=*I2? 

ELSE  IF  PEQREL . PROC. I  DM^UEUE .  PROC.  I D  ( *W.QUEUE*PROC  _  I D  ( 1 )  ■  *  1 2  >  THEN  IF 
*12=1  THEN  QUEUE. IN.XXC«I2»*1« 

ELSE  imiE.IN.IX(iI2)=*3UEUE.IN.IX<«I2-l>+t; 

ELSE  IF  *12=1  THEN  «JEUE. IN_IX(*I2>=2: 

ELSE  QUEUE.  lN.lXf*I2)=GUEUE. IN.IX f *12-1 
IF  PEQREL . RO j3R.RL='RE0'R*I2=SIZE*0UEI.IE-PR0C( 2 1  THEN 
QI.I0JE .  PROC.  I D  ( *W_QLIE|JE*PPOC_  I D !  2 )  -  *  1 2 )  =REQREL .  PROC-.  I  DM: 

ELSE  QIJEUE .  PROC.  I D  ( *W.QUEUE*PROC.  ID  ( 2 )  •  *  1 2  > = 

QUEUE. P«OC_IDf *«-QUEUE*PROC_ID( l) -QUEUE. IN_IX<*I2> l! 

END: 


*ERRijR='1  9  : 

i JNSPEC I REQREL .  CL0CKRM  >  =UNSPEC  <  SUBSTR  ( REQREL.MS.'SRM.S  •  REQREL-MSGRM .  I  NO*  •  10  '  ’  '• 
REQREL. CLOCKRM  =  REQREL. CLOCKRM  : 

IF  iERROR  THEN  tERROR- 'OB  ’ 

REOREL-MSGRH. I NQX  =REQREL_MSGRN_ INOX+IO  : 

3 1  Ml  il.  AT  I .  CLOCKRMsREOREL .  CLOCKRM : 

00  *12  =1  TO  5: 

*ERROR='l  R  : 

i  INSPEC  < REOREL .  RESM )  =i  WRPEC  < SUBSTR  t  REQREL-MSGRM _S  •  PEQPEL.MSWM .  ? NOT .  m  : 
REQREL. RESM  =  REQREL. RESM  : 

IF  lERRfiR  THEN  *ERR'0R='0'B  : 

REQREL-MSGRM. INBX=REQREL.MSGRM_INDX+ 1  s 
SIMiJLATI .  RESMl  *I2)=REQREL.  RESM: 

00  *13  =t  TO  S I ZEWJEUE .PROC ( 2 ' : 

IF  REQREL. RQ.0R-RL=,REQ,V*I3=S1ZE*QI.€UE_PRCC(  2'  TWFN 
QUEUE .  CLA I M  < *W_OUEUE*CLA  IM(  2 ) .  *  1 3-  *  1 2  >  =REQREL  .RESM: 

FLSE  QlJEl IF.aAIMI *W.i5UEUE*aAIM( 2! . *13.  *I2'=QUEUE. CLAIM' *U_QUEUE«CLATH r 
•QUEUE. IN.I<(*I3'>*I2': 

IF  *13=1  THFN  QlJEl  IE .  Si  IM.REQ  <  *  1 3  •  *  1 2 '  =QIJEIJE .  CLA  I M  ( tW  _QUEUE*CLAI M  ( 2 '  •  * !  3  • 
*I2'‘. 

Ei  SF  r.|  i£i  i£ ,  si  IM.REQ  ( *  1 2.  *  1 2 '  =QUEU£ .  CLA  I M  ( *U  .QUEUE*!  i_  A I M  ( 2 '  • « 1 3  •  * !  2  ’  ♦ 
QUEUE. RUM  REO'*I3-l-*12': 


IF  *12=1  THEN  &UEUE .  SAT  ( tW.QiJFUEt'RAT 2 '  -  *  1 3  -  *  1 2 '  =OUEUE .  5U*  RE0**I3-«I2' ■•' 
INTERIM,  NlJH.RESi*I2) !  QUEUE.  CLAIM*  *M_QUEUE*CLAIN<  2'  •  *13.  *1 2'  =<>•■ 

ELSE  « 10  € .  sAT  f  *H.M  ©  l£*SAT  ( 2 ' .  *  1 3 . 1 1 2  >  =QUEl  €  .SAT*  tu  Oi  ©  IF4SAT  *  2 '  -  *  I  <- 
*  1 2- 1 '  i ;  QUEUE .  SI .IK.!®!  *  *  1 3 .  *  1 2  K= INTER  I M .  NlJM.RES  <*12»: 

QUEUE .  CLA I M '  tW  .QUEUEtCLA  l N ( 2 ) • t l 3 - * l 2 ' =0 ’ : 

END: 

END: 

DO  *12  =l  TO  SI It*QUEUE_PROC ( 2 ) : 

IP  flEMEL.MLORJIL='REL'  THEN  IP  QUEUE .  SAT ( 4U_QIJ0JE*SAT *  ?  L  *  1 2.  S '  fcA 
i3UEL€.SAT(*WjX©JE*SAT*1), QUEUE. !N_IX<*12>- 5'  THEN  IP  *12=1  THEN 
QUEUE. QUT.IX <  <I2)=U 

ELSE  QUEUE.0UT.IX<*I2)=QUPJE.0UT_r<**I2-l >+t; 

ELSE  TF  *12=1  THEN  QUEUE. 0UT_I***I2)=O? 

ELSE  QUEUE .  OUT  _  I X  *  *  1 2 '  =OUEUE .  OUT  _  I K  *  1 12- 1 ' 

-LSE  IF  *I2=SIZE*QU0IE  PROC ' 2 '  MS  ©  IP .  CAT  •  *W  .M  €‘  IF*SAT  *  2 '  -  *  1 2  •  ^ 1  thPN 
Oi  ©IE  .PH  IT  I<(*I2'=l: 

FLSE  Oi  (Ft  IE.  out  I<(*12'=0: 

IF  *12=1  &QUEUE .  OUT.  I X  ( *  1 2  V =  1 1  *  1 2>  1  &QUEUE .  CUT.  I  '*'*12'  DQUEUE .  OUT  .1*1*12-'.' 
THFN  ALLOT.  PUKKA*  W  ©  € .  01  F  !»<*I2*  '=*®3REL.CLFCi*RM: 
tlSF  : 

IF  tl2=l.LOHEHE.filiT_I*(*I2'=l  !*I2%lNOllFHE.0LlT.lX(*I2'''QL©€.Oirr  I X  ■  *  1 2- 1’ 
then  ALLOC . PROC. I D ( QUEUE . OUT _  I X  ( 1 1 2  "  =i‘ HPTRLB *  *  'ALLOC' ! ! 

LEFT ,.t i QUEUE . PROC  IB<*W.QUEUE*PROC  10(2'. *12" ! I 'S  MB*’": 

ELSE  s 
END: 

i F  ? I ZE*OUEUE.PR0C * 2 ) >0  THEN  S I ZE* ALLOC_MSGA=QUEUE .CUT. I** S ! ZE*QUEL€ .PROC * 2 » 
ELSE  S I ZE*ALL0C.MSCA=O: 

DO  *12  =1  TO  SIZE*ALL0C_M3GA: 

SI  Ml  AT  I .  CLOCK  A  ( *  1 2 '  =  ALLOC .  CLOCK  A  i  *12': 

S I MJLAT I . PROC_ I DA ( * 1 2 ' =SUBSTR ( ALLOC . PROC-  ID  *  1 1 2 )  •  -S- 1 ' 5 
ALLiX.MSGA.INDX=t: 

SUBSTR* ALLOC. MSGA.S.F. ALLX-MSOA.INDX.  1 1  >=ALLOC. PROC.ID*  *1?'  : 
ALLOC.MSGA.INDX=ALLX.MSGA.INDX+l  1  : 

SUBSTR  ( ALLOC.MSGA.SC .  ALLOC.MSGA.  I NOX *8-7 .  R*8  >  =IJN$PEC  <  ALLOC .  CLCO'A  *  *  1 2  "  : 
ALLCC _MSGA_INDX=ALLX -NSGA.  INDX+P  : 

ALLOC_MSGA.S=SUBSTR(ALLX.MSGA.S.F.  1 -  Al.LOC.MSC«A_  I NDX  - 1 ' : 

STS* V ALUE=SVS*ASS I GN ( CHPTRLB  * ALLOC . PROC. I B ( * 1 2 ) ' -CHANNEL- ..): 
tf  ASTS*SUCCESS  THEN  00? 

PUT  SKIP  LIST * '**WARNING:  NO  CHANNEL  ASSIGNED  TO  ALLOCT?')! 

PUT  SKIP  LIST*'**  MESSAGE  DEPOSITED  INTO  ALLCCT. BAT' \ : 

URITE  FILE* ALLCCT)  ROM  * ALLOC.MSOA.S ' : 

END! 

asE  DO? 

STS*V  ALUE=SVS*Q  1 0  *  l, CHANNEL.  IO*.HRITEVBLK+IO*M.NOH-  I0.STAT1JS- . . 

ADDR ( ALLOC .MSGA.S.F i - LENGTH ( ALLOC .MSOA.S ' 

[F  ASTS*SUCCESS  THEN  PIJT  SKIP  LIST*  'WRITE  QIO  UNSUCCESSFUL ^ '  s 
STS*VALUE=SYS*WAITFRU): 

ST  S*VALUE=SYS*DASSGN  * CHANJ€l ) ? 

END: 

S  T  MJL  AT  I .  F  i  LLER5  ( « 1 2  > = '  '? 

S I mijlAT I. FILLERS (*I2l=/  ': 

FNO: 

OUFUE.PPOC.Q_INDX=1; 

DO  *12  =1  to  SIZE*GUEUE-PR0C*2): 

SUBSTR  ( CHJEUE_P*W5C_Q_SC .  iJUEUE  .PROC.Q.  INDX*S-T  -1*8'= 
UNSPEC'QIJEIJE.PR0C.I0(*«-QUEIJE*PR0C_ID*2' - *12) '  : 

Q»JBJE_PROC_CLINOX=QUEUE.PRQC  _Q_INDX*1  : 

SUBSTR  *  QL©JE-PR0C_0 .SC .  QlJEUE.PRGC.Q.  INDX  *8-7 -  8*8 '  =UNSPEC ( QUEUE .  IN.!  X  >  *1 2 ' «  s 
QUEUE.PROC.Q_ I NDX=QIJEUE -PROC . Q. I VD  X +R  : 
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<aiKTR(ajBJEJ,R0C.0.5C.MUEUE_PR0C  0  INDX*8-7.  <  *:? >  =mnSPEC ■' QUEUE . >'n  ‘T _ r» .  -i I Z >  *  : 
ftUEUE.PRQC.Q.  I  NOX=ftUElJE_PROC_Q_  I NDX+  i  : 
in  tf-i  =i  Tft  c: 

S! IBSTR ( OUEUE.PROC.A.SC > QtJE*JE_PROC-  Q  INBX«8-7,  i*gt= 
ijNSPEC ( QUEUE . CLA I M ( *W_QUEUE*CLAIM( 2  > • * 1 2, *1 3  H  : 
tjiJEUE -PRCtC  _  a_  I  NO  *  =vUEUE  _PRCm:  _q  _  I ND  X  ♦  1  : 

■5! IBSTR f 0» IFI iE  PMf  ft  Sf-.ftldC  PROC  Q  INOXtft-7. U8W*SPK««P€.SUMJ!EO<it?. 

ii-3"  ; 

*XiEI.»E_PROC_C'_  IN0X=QL€Le_PR0C_9_  I ND  <+ 1  : 

SI  IBSTR  ( ftijElJE.PROC.Q.SC.  OUEUE-PROC.Q-  INDX  *8-7 .  1*8  >= 

IJNSPEC  i  QUEUE .  SAT  ( «W_QUEUE*SAT  ( 2 » - * 1 2 .  *  1 3  H  : 
OljEUE.PROC_Q_INBX=tmiE.PROC-ft.INDX*l  : 

END! 

END: 

ft!  I-IIF  poor  ft  SsS! IBPTROftllEME  PPftf  0  S  F.1.0©*  PWV  0  INDX-!'J 
Ufti"  7T,i  E'ftllPiCT'.  PRfiH  i«PF  PPftf  ft  si: 

SIMUlAT], FILLERl-  : 

S:WLATI.7!LLEP2=' 

SWLATt.FU.LER3-'  : 

SIMlJLATT. FILLER^"' 
ft  t  il  l!.  AT  I  .EVENT.  I ND  X= 1 : 

SUBSTR  ( S I  MIJLATI.EVENT.S_F .  S I MULAT I  .EVENT.  I NBX , 4 1  =S I IHJIAT I .  PROC  .  I  DM  : 
SIMULATI.EVENT_INDX=SIMULATI_EVENT.INDX+4  : 

SUBSTR  <  S I  MIJLAT  I  .EVENT.S.F .  S I  MIX  AT  I  .EVENT  .INDX.  1  >  =S  1  MI.HAT  I .  F I LLER 1  : 

S I  MIJI.AT  I  .EVENT.  INBX=S  I MIJLAT I  .EVENT  JNDX+1  : 

SI  i&RTR  ( s !  Ml  ILAT I  .EVENT  s.F.  SI  Ml  HAT  I  .EVENT  IN0X,3I=SIHULATI.RQ_0R  PL  : 

I  Mi  >i  ATT_£i;fmt  I  NO X  =P  I MLH. AT  I  .E VENT  .  J  NO X + '<  : 

SUBSTR (i IMULATI.EVENT.S_F.SIMI.il ATI. EVENT  INDX .  t  '=SIMULAT! . PILLER'2  : 

S I  MIJI.AT !  .EVENT.  1  NDX=S  I  Mi.il.AT  I  .EVENT  .INQX+1  : 

no  $i2  =i  Tn  Si 

SUBSTR  ( S I  MULAT  I  .EVENT.SC .  3 1  MIJLAT  I  .EVENT.  INOX  *8-7.1*81= 

IJNSPEC  ( S I  MULAT  I .  RESM  (*I2>  >  : 

SIMULAT  1  .EVENT  _INM=81t«JLAT  I  .EVENT  _1NM  M  : 

end; 

SUBSTR 1 S I  Ml  ILAT  I  .EVENT.S.F .  S I  MULAT  I  .EVENT.  I NDX .  1  '=S I MULAT I. FILLERS  : 
SIMI.«.AT!.EVENT.INDX=SIMI.LATI.EVENT.IN0X+1  : 

SUBSTR  ( S  IMi.lLATI  .PJENT.'SC-  SIMULATI  .EVENT. IN0X*8-7 . 1 3*8  IJNSPEC  t  SI  MIJLAT  I ,  CLOT^'M  l 

SIMULATI.EVENT.INDX=SIMI.ILATI.EVENT.IN0X+13  : 

SUBSTR  *  S I  HlXAT  I  _EVENT_S_F .  SIMULAT I  .EVENT.  IHDX  T  2 )  I  MULAT! .  F I LLEP4  : 

S I  MIJLAT  I  .EVENT.  I  NBX=S  I  MULAT  I  .EVENT.  I NRX+2  : 

00  *12  =1  TO  SIZEtALLCC.MSGA: 

SUBSTR  ( S I  MIJLAT  I  .EVENT.S.F  ■  SIMULAT  I  .EVENT.  INDX .  1 )  =3 1  MULAT  I .  F I  I.LERS '  *  1 2 )  : 

S I  MULAT  I  .EVENT.  INDX=SIMIJLAT  I  .EVENT.  INDX  *  1  : 

SUBSTR  ( SIMULAT  I  .EVENT  .S.F  ■  S I  MIJLAT  I  .EVENT -INDX ,  4 '  =SI  MIJLAT  I ,  PROC.  I  DA f  *  1 2 '  : 

S :  MIJLAT  I  .EVENT  .  I  NBX=SI  MIJLAT  I  .EVENT.  I  NDX  *4  : 

SUBSTR  I S I  MIJLAT  I  .EVENT  _S  _F ,  SIMULAT  I  .EVENT  .INDX- 1  '=SIMLHATI.FILLERB<*I2J  * 

S I  MULAT  I  _ EVENT  _  I ND  X  =-5 1 HIJL AT  I  _ EVENT  _  I  NO  X + 1  : 
SIJESTR(SIMIJLATI.EVENT.SC,SIMULATI.EVENT.INDX*8-7.13*8'= 

'  INSPEC ( SIMULAT I . CLOCK A  <  *1 2  >  x  : 

S:muLAtI.EVENT.INDX=SIMIAATI.EVENT.IN0X+13  : 

END: 

:  tmi.«l  AT  T  _EVENT_S=SOBSTR<  SIPIULATI  _EVENT_S_F-  i-SIMULATI. EVENT.  INDX-1 ' : 

WRITE  FILE'SIMULATITI  FROM  -SIMULATI .EVENT _SI: 

TR  END*REQREL.MSGRM ( 2 )  THEN  tNOT.DONEd'-'O'B: 

SIZE*0UEUE_PROC 1 1 )  =  SI  ZE«HJEUE_PROC  ( 2 '  ’■ 

ENDtREftREL.MSGRMUl  =  ENDSREQREL_WSGRM'2) : 

: ALL  SROTATE 1  *U.ftiJEUE*PR0C:_ID-2 ) : 

■lAi  l  5P0TATE ■'  tW.OUEUEtSAT.  2  > : 

CALL  $ROT ATE ■' tU-QUEUEtClA I M ,  2' : 

END: 

'LOSE  >ILE' ALLOCT': 

CLOSE  F]i.E 'QUEUED; 
ft'jiSE  FlLE'SIMULATITi; 

RETIIPN: 

END  P: 


ONF r nr rRATT°M  PO''1  'MENTATION 


444444*4+4*4*4444 444*4t4444444444t4444444444444444444444»4*444444*4444444 

♦  LISTING  OF  SPECIFICATION  * 

t  CONFIGURATION:  PR: 

2  Ms  Pt.P2,P?,P4.pE  ->  F:  REOREL  {ORfi:NAIL> 

3  -2  M:  MONITOR  ->  F:  ALLOCT  I QRG: PORT ' 

4  Fs  ALLOC  IS  i  ORGtMAlL''  ALLOC IS  (f»G:MAII  K  «  LOCSF  fORGsMAU 

c  ALLCC4S  iORGiMAIL' •  ALLANS  .TIRO: MAIL o 


k  Pi 

F: 

S  F: 

•5  F: 

10  F: 

ALLOC  IS  -:  MS  PH 
ALLQC2S  ->  M:  PJ: 
ALL0C3S  -o  MS  PS: 
ALL0C4S  -■■■  M:  P4: 
ALL0C5S  m:  PE: 

44444444444444444444444444444444 

4  CONFIGURATION  REPORT  4 

44444444444444444444444444444444 

44444444444444444444444444444*4*4444444»***« 

*  Msec  REPORT 

444444444*444»4444444444444444*4444*4444<MH>t 

NAME 

;  itit 

•  !234%7590t23 

MSCC#  NODE  NAME 

!  MONITOR 

allc«:t 

ALLOC IS 

PI 

PEOREL 

ALL0C2S 

py 

ALLOCS? 

c? 

TYPF 

MODULE'S' 

1  MONITOR 

2  PI 

'<  P  v 

4  PS 

5  P4 

A  PE 

4 

!  V 

!  V 

!  0 

:  v 

:  V 

:  y 

MDL 

FILE 

FILE 

MDI 

FILE 

FILE 

MOL 

FILE 

MDL 

FiLEISi 

♦ 

ALL0C4S 

P4 

PILE 

MTi( 

7  Al  1  Of: IS 

S  ALL0C2S 

R  ALL0C3S 
to  ALLOC*? 

U  ALLOC SS 

1 2  Ai  uXT 

IS  PEORtL 

:  v 
!  V 
!  V 

:  v 

;  v 

:  vww 

:v 

ALL0C5S 

PE 

FILE 

Mil 

444444444+4**444*44+*444444444444444444#*4444*4444*444*44*44»4444»4*4*»4»4*+4*Ih> 

♦  MnL /FTI  =  RFT  5TP0RT  , 

♦44****4****4*4**4*******+*444*4**4*4**4****4**444***4*444#*****4*444*4*4444,.*»+ 

—  MOrnjLE  r-PFF  — 

MOL:  MONITOR 

- .NAME:  MONITOR 


•synonyms  SOURCE 


TAP0ET  svnc.aftfr  paps:  r 
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MOL:  PI 

P.NAMF:  PI 

SYNONYMS  SOURCE  TARGET  SYNC. AFTER  PAR#:  1 


Ai.LOC  15  /VIRTUAL  REQREL  /VIRTUAL 


mol:  P2 

P.NAMF:  P2 


PS 

pi 

p\ 

Pi 

pi 

MONT TOR 


SYNONYMS  SOURCE  TARGET  RVNT , AFTPR  PAR#:  ! 


AllOC 25  'VIRTUAL  R'EOREL  ''VIRTUAL 


htil:  P'5 

R>iAME:  PT 

synonyms  soijrce  target  sync,  after 

ALLQC3S  'VIRTUAL  REOREL  /VIRTUAL 


MOL:  P4 

P.NAMF:  P4 

SYNONYMS  SOURCE  TARGET  SYNC.  AFTER 

ALLOC4S  /VIRTUAL  REOREL  /VIRTUAL 


MDl:  P*5 

P.NAME:  P5 


ps 

PA 


P< 


P? 


PI 

MONITOR 


PAR#:  t 

PS 

PA 

PS 

pi 

PI 

MONITOR 


PAP#:  I 

PS 

PA 

PS 

pj 

pi 

MONITOR 


SYNONYMS  SOURCE 


target 


SYNC. AFTER  PAR#:  I 


ALL0C5S  /VIRTUAL  REOREL  /VIRTUAL 


-  FILE  <-REF  - 

FILE:  ALLOC IS 

P  .NAME:  ALLOC: IS 

(COMPATIBILITY  REQUIRED' 

SYNONYMS  PRODUCER  CONSUMBEP  ORGANIZATION  REC  SIZE 
ALLOC"  F'l  MAIL/VIRTIJAL  200 


PS 

PA 

P'S 

P2 

PI 

MONITOR 


PAR#: 


PS 

PA 

PS 

Pi 
=  1 

MONITOR 


HIE:  ALLOC 2$ 

P  NAME:  ALL0C2S 


'COMPATIBILITY  REQUIRED) 

SYNONYMS  PRODUCER  CONS'JMBER  ORGANIZATION  PEC  SI7F  PARS:  I 


ALLOCT  P2 

MAIL/VIRTUAL 

300 

PILE:  ALLOCSS 

P  .NAME: 

ALI  OTSS 

'COMPATIBILITY  REWIRED) 

SYNONYMS 

PRODUCER  CONS' JMBER 

ORGANIZATION 

RFC 

MAIL /VIRTUAL  300 


PILE:  ALLOCAS 

P  NAME:  ALL0C4S 

'COMPATIBILITY  REWIRED) 
SYNONYMS  PRODUCER  CONSUMBER 

ALLOCT  P4 


FILE:  ALLQCjS 

P.NAME:  ALL0C5S 

'COMPATIBILITY  REQUIRED) 
SYNONYMS'  PRODUCER  CONSUMBER 


ALLOCT  PS 


FILE:  ALLOCT 

P.NAME:  ALLOCT 

'COMPATIBILITY  REQUIRED) 
SYNONYMS  PRODUCER  CONSUMBER 


p? 

P! 

MONITOR 


ORGANIZATION 

REC  SIZE 

PAR*:  I 

MAIL/VIRTUAL 

300 

PS 

P4 

PS 

PZ 

Pt 

MONITOR 

ORGANIZATION 

REC  SIZE 

PAR*:  i 

MAIL/VIRTIJAL 

300 

PS 

P4 

PS 

PS 

pt 

MONITOR 

organization 

REC  SIZE 

PAR*:  ' 

-  191  - 

-I!  P:  SEijfcEi 

P_NAMF:  REQREL 

< COMPATIBILITY  REQUIRED) 

SYNONYMS  PRODUCER  CONSUMBER  ORGANIZATION  REC  SIZE  PAW:  1 


MONITOR 


MAIL/VIRTlJAL  300 


P'5 

P4 

P- 

P'- 

pi 

MONITOR 


♦  CROSS  REFERENCE  REPORT  * 

NAME  M/p  TYPE  REP.NAME  PHSICAl  NAMF  INFORMATION 


NAME 

m/p  type  REP.NAME 

MONITOR 

M 

MDL  MONITOR 

MONITOR 

PI 

M 

Mil  PI 

Pi 

P2 

M 

MDL  P2 

P2 

PS 

M 

MDL  PS 

PS 

P4 

M 

MU  P4 

P4 

PS 

M 

MDL  P'5 

PS 

ALICE  IS 

P 

MAIL  A  ICC  IS 

ALLOC IS 

ALL0C2S 

P 

mail  ALLOC IS 

ALL0C2S 

ALL0C3S 

F 

MAIL  ALL0C3S 

ALL0C3S 

ALL0C4? 

F 

MAIL  ALL0C4S 

ALLCC4S 

ALL0C5S 

F 

MAIL  AL10C5S 

ALL0C5S 

ALLXT 

P 

POST  ALLOCT 

ALLOCT 

REQREL 

F 

MAIL  REQREL 

REQREL 

UHERE  IT  IS  IE" 'NED 


*  PAR.  COMPONENT  REPORT  ♦ 


Th«  PAR.  COMP?: 


pAR.  COMP*  NODE  NAME 


ACTION  PHYSICAL  NAMF 


MONITOR 

MDL 

SUBMIT 

MONITOR 

ALLOCT 

PILE 

ALLOCT 

REQREL 

PILE 

RCQRE> 

ALLOC IS 

PILE 

- - — 

ALLOC  1~S 

ALL0C2S 

PILE 

- - 

Ai  l  .T2S 

ALL0C3S 

ALLOT 4S 

PILE 

PILE 

ALLCC3S 
Ai  LOT 4S 

ALLOTS 

PILE 

At  LOTFs 

pi 

MDL 

RIIBMIT 

PI 

P2 

MDL 

SUBMIT 

P2 

P3 

MDL 

SUBMIT 

PR 

P4 

MDL 

SUBMIT 

P4 

MDL 

SUBMIT 

PS 

PAR.  : 
COMP*! I 


Pel'll)?!  CYMMOn^T  *%trl 


I 


192 


*  .'CL  PROGRAM  report  » 

I,  The  main  jCL  orogram  <RR.COM) 

tPl  I  PR 
■SLINK  ftp 
♦RUN  RR 

♦SUBMIT/NAME=M0NTT0fi  MON I TOR 
♦Rll8MIT/NAME=Pl  Pf 
♦SUBMIT /NAME=P2  P2 
♦sllBMIT'NAME=PR  ?'< 

♦silBMIT/NAME=Pi  pi 
♦EIIBMIT/naMFPS  PS 
{•  ~Mfi  OF  ONE  POP  COMP 


*  JCL  Program  Cor  P 3  'Pj.CC'M' 

♦DEFINE  ALL0C3S  A1  LOC3S.M6X 
*  DEFINE  REPEL  REPEL.MBX 
{RUN  PO 

♦DEASS  ALLCC3S 
♦DEASS  REQREL 

*  .JCL  Program  for  P4  IP4.COM) 

♦DEFINE  ALL0C4S  ALL0C4S.MBX 
♦DEFINE  REPEL  REOREL.MBT 
♦RUN  P4 

♦DEASS  ALL0C4S 
♦DEASS  REPREL 

*  JCL  Program  for  P*>  « P“* . COM > 

♦DEFINE  ALL0C5S  ALLOC5S-MRX 
♦DEFINE  REPEL  REPEL.NBX 
♦RIW  P5 

♦DEASS  AU.0C5S 
♦DEASS  REPEL 


3.  The  mailboy  creation  PL/I  program  IRR.Pl.I) 

CREMBX:PROC  OPTIONSIMAINi  REniRN$(FT<ED  RINnii): 
’/.INCLUDE  SYS4CREMRX: 

‘/.INCLUDE  SYS4ASSIGN: 

•'.INCLUDE  tSTSDCF: 

DCL  HBX.NAME  CHARI  151  VP: 

DCL  PERMANENT  FIXED  6INi3I)  STATIC  iNirq  ,, 

CHANNEL  FIXED  RINllSi. 
mAX.lENOTH  FIXED  RINI31'  STATIC, 

PROT.MASF  BITf l*>  ALIGNED  STATIC  INF,  TF0.VR4). 
MAILBOX  .NAME  STATIC  CHARI  ISi  VP: 
MAILB0X.NAME='ALLP1S  MAX': 

MAX  I  ENOTHr 


I,  The  jCL  program?  t-or  each 

*  JCL  Program  for-  MONITOR  /MONITOR. COM) 

♦DEFINE  PROPEL  REOREL.MBX 
♦RUN  MONITOR 
♦OEASS  REPEL 

*  JCL  Program  for  Pi  iPl.COM) 

♦DEFINE  ALL0C1S  ALL0C1S.MBX 
♦DEFINE  REOREL  REOREL.MBX 
♦RUN  PI 

♦DEASS  ALLOC IS 
♦DEASS  REOREL 

*  JCL  Program  for  P2  iP2.COM) 

♦DEFINE  ALL0C2S  ALLOC 2S.MRX 
♦DEFINE  REOREL  REOREL.MBX 
piin  P2 

♦DEASS  ALL0C2S 
♦DEASS  REOREL 
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"itV6LL€=-3V?KRE«fi»iPE?;MaN£itT.rwANNEL. 

MAX.LENOTH- .pROT.MASk. -MAI'  BAV  diAMP.i 
"ft! -B0'»'.>WHE=-'ALL«2S  W- 

MAX  _LENOTH=30tl : 

STStVALUE=SVS*CREMRX  ( PERMANENT. CHANNE1  • 

MAX .LENGTH, , PROT.MASK • . MAILBOX  NAME' : 
MAILBOX  _NAHE='ALL0C3S_HBV  •' : 

MAX. lENGTH=  wo; 

3.T3iVALUE-SY3.*f:R£MBX(PEPMANENT-rHANNEi  • 

MAX  .LENGTH.  .PROT.MASK., MAILBOX  NAME'; 

MA I LBOX  .NAME- '  ALL0C4S.MBX / ; 

MAX. LENGTHS 300; 

STStVALUE=SYS«CREMB* ;  PERMANENT  -  CHANNEL  • 

MAX .LENGTH,. PROT.MASK. -MAILBOX  NAME'; 
MAlLBOX.NAME-  AIL0C5B  MB*'': 

MAX  .lENGTH=3Tm1; 

ITS  WALUE=SYB*CBEMBX  <  PERMANENT .  CHANNEL. 

MAX .LENGTH.. PROT.MASK. .MftlLROX  NAMF'; 

MA  I  l.BOX  .NAME- REOREL.MBX ' :  ' 

MAX  .LENGTHs  300 : 

I TStVALUE=SYS$C  REMAX ( PERMANENT . CHANNE'  • 

MAX. LENGTH,  .PRQT.MASK. , MAILBOX  NAME! ; 
RETURN' STSt VALUE ' ; 

END  CREMBX: 

A.  The  (Mil box  deletion  PL/I  orosram  'RRD.RLI' 

DELMBX ; PRiX  QPTIONS'MAIN'  RETURNS i FIXED  RINni": 
XINCLUK  SYStOELMBX: 

‘■i  INC  LUBE  SYStASSIGN: 

"i INCLUDE  iSTSBEF; 

OCL  Mpx .NAME  CHAR ( 15 >  VAR: 

DCL  PERMANENT  FIXED  BIN'S!'  STATIC  INIT.  T», 

CHANNEL  FIXED  BIN*'  l6!'. 

MAX  .LENGTH  FIXED  BINHlt  STATIC. 

PROT.MASK  BIT' 16'  ALIGNED  STATIC  INIT' 'FF0IVR4'. 
MAILBCiX.fWME  STATIC:  CHAR' 15'  VAR; 
MAILB0X.NAME-ALL0C1S.MBX': 

max.length=w; 

■:TStVALLE=SYS*ASSIGN(MAILBCiX  NAMF.CWannE' 

IF  STStSUCCESS  then  pit  Sk'IP  LIST! -'ERROR  IN  ciRlmbx-m 
STStVSLUE=SYS«riELMBX(C.HANN0  i; 

MA I LBOX .NAME= " ALLOC  2S  MBX ' ; 

MAX. LENGTHS joo; 

STStVAI.UE=SYS»ASSIGN(MAILB'OX.NAMF.rHANNFI  . . . 

IF  'ST'-.iSUCCESS  thfn  put  skip  i  isT'-'FRPriR  in  [iPlmrx-i 

sTstvAujFssvstoaMBx  i  channel  ' ; 

MA  I  LBOX  _NAME= -  ALLOCSS,  MBX-'; 

MAX. lENGTHs  wi; 

■;  TS*VALUE=SYS*ASS  I  ON  '  MA  I  LBOX  NAME.  CHANNEL  -  ■ .  > : 

IF  'STStSUCCESS  THEN  put  Sk'IP  LIST! 'ERROR  IN  OELMBX " ' 
STS*VALl€=SYS*C€LMBX i CHANNEL ' : 
mAILBOX.NAME='AI.lOC4S  MBX'; 

MAX.  LENGTHs  Wi; 

StS*VALUE='SYS*ASSIGN(MAIL90X  NAME, CHANNEL-  >  - '; 

IF  "STStSUCCESS  THEN  put  Sk'IP  1 1ST '  FRROR  in  op  MBX  ' 
STS*VALL€=SYS*TiELMBX'  ChawE'  ' ; 

MA  I  LBOX  _NAME= '  ALLOC  5S  MB'* ' ; " 

MAX.  LENGTH*  wi; 

STSlVALL€=SYStASSIGNiMAILBOX.NAMC. CHANNEL. . .  < : 

IF  STStSUCCESS  THEN  PUT  Stir  LIST' 'ERROR  IN  [iFLMBX ■' ' 
STSiVALUE=SYStOELMBX 'CHANNEL  ' : 

MAILBCiX.NAHE=  'REORFL-MBX  ; 

MAX..ENG"HsVi(1; 

•■:TStVALUE=SYStASS  I  ON  (MAI  LBOX  .NAME.  CHANNEL. . .  t; 

IF  '? •  :*SUCCESS  thrn  put  Sk’IP  LIST'  frrciS  tw  O0MBX  ' 
STStVALLEsSYStDP.MBXiCHANNp  '.; 

RPTIJRN'STStVALUE'; 

END  DELMBX: 
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REP  01100 
REQ  11000 
REP  00110 
REP  10001 
REP  00011 
REL  ciiOO 
REQ  OUOO 
REL  11000 

rep  1 1  (>:«:* 

REL  00110 
REP  001 10 
REL  10001 
REQ  10001 
REL  01100 
REP  01100 
REL  00011 
REP  00011 
REL  11000 
REP  11000 
REL  00110 
REP  00110 
REL  10001 
REQ  KiOOl 
REL  01100 
REQ  01100 
REL  00011 
REQ  00011 
REL  11000 
REP  11000 
REL  00110 
REQ  00110 
REL  10001 
REQ  10001 
REL  01100 
REQ  01100 
REL  00011 
REQ  00011 
REL  IKKh) 
REQ  tlOQO 
REL  00110 
REQ  'WHO 
REL  tOOOt 
REQ  10001 
REL  01100 
REQ  01100 
REL  00011 
REQ  00ft 11 
REL  11000 
REQ  11000 
REL  00110 
REP  00110 
REL  10001 
REQ  10001 
REL  01100 
REL  00011 
REQ  00011 
REL  11000 
REL  00 HO 
REL  10001 
REL  0001 1 


A1.4  SIMULATION  REPORT 


REQUEST 

P-1D  R/L  RESR'C  TIME  PJD 


TIME 


ALLOCATION 

PJD 


TIME 


PJD 


TIME 


000015461434 

00001546201? 

000015462374 

0000 1546308 A 

00001 54631 R8 

00001546.354ft 

000015463^49 

00001546361 l 

000015463612 

0000 154636 15 

000015463617 

'300015463639 

000015463640 

000015463662 

000015463664 

000015463686 

000015463697 

000015463709 

000015463711 

000015463733 

000015463735 

000015463757 

000015463758 

000015463782 

000015463784 

000015463805 

000015463807 

000015463829 

00001546.3831 

000015463858 

000015463860 

000015463884 

000015463885 

000015463909 

000015463910 

000015463935 

000015463936 

000015463958 

000015463959 

000015463983 

'WOO  15463984 

000015464006 

000015464008 

000015464030 

000015464032 

000015464058 

000015464064 

000015464103 

000015464104 

000015464165 

000015464166 

000015464207 

000015464209 

000015464239 

000015464311 

000015464312 

00001546*347 

000015*64385 

00001546*439 

000015*64457 


000015*61434 

000015*63548 

000015*63611 

000015*63615 

000015463639 

000015*63662 

'WOO 15463686 

000015463709 

000015463733 

000015463757 

'WOO  15*63782 

000015*63805 

000015*63829 

000015463858 

000015463884 

(100015463909 

000015463935 

000015463958 

000015463983 

000015*64006 

000015464030 

000015*6*058 

000015*64103 

00001546*165 

000015464207 

00001546*239 
000015*6*31 1 

000015*643*7 

000015*64*39 


(*0001 5*635*8 
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A2 .  THE  COOPERATIVE  COMPUTATION  EXAMPLE 


The  example  presented  in  Part  I  is  an  extremely  simplified  one. 
The  real-life  example  of  the  cooperative  computation  is  presented  as 
the  follows. 

A2.1  SYSTEM  CONFIGURATION 


w 


F 


CONFIGURATION:  PBEM;  /*  PACIFIC  BASIN  ECONOMETRIC  MODEL  */ 
F:  TSDUSAS , CTRUSAS , 1 1USAS  (ORG:  MAIL) 

->  M:  USA 

->  F:  02USAT,  OIUSAT  (ORG:  MAIL); 

F:  TSDJAP ANS,CTR JAPANS, I 1 JAPANS  (ORG:  MAIL) 

->  M:  JAPAN 

->  F:  02 JAPANT ,  01JAPANT  (ORG:  MAIL); 

F:  TSDTWNS , CTRTWNS , I 1TAIWANS  (ORG:  MAIL) 

->  M:  TAIWAN 

->  F:  02TAIWANT,  01TAIWANT  (ORG:  MAIL); 

F:  TSDPHILS,  CTRPHILS, I1PHILS  (ORG:  MAIL) 

->  M:  PHILIPPI 

->  F:  02PHILT,  OIPHILT  (ORG:  MAIL); 

F:  TSDTHAIS,CTRTHIS, I1THAIS  (ORG:  MAIL) 

->  M:  THAILAND 

F:  02THAIT.  OITHAIT  (ORG:  MAIL); 

F:  TSDKOREAS , CTRKRA , I 1KOREAS  (ORG:  MAIL) 

->  M:  KOREA 

-»  F:  02K0REAT ,  OIKOREAT  (ORG:  MAIL); 

F:  TSDWRDS , CTRWRDS , 

USAS  (ORG: MAIL), 

JAPS  (ORG: MAIL), 

KRAS  (ORG: MAIL), 

TWNS  (ORG: MAIL), 

PHIS  (ORG: MAIL), 

TAIS  (ORG: MAIL) 

->  M:  WORLD 

->  F:  O2W0RLDT,  OIWORLDT  (ORG:  POST); 

F:  OIWORLDT 

->  F:  I1USAS, I1JAPANS, I1TAIWANS, I1PHILS, I1KOREAS, I1THAIS; 
S:  OIUSAT, USAS; 

S:  Ol JAPANT, JAPS; 

S:  01TAIWANT,TWNS; 

S:  OIKOREAT, KRAS; 

S:  OIPHILT, PHIS; 

S:  OITHAIT, TAIS; 


roNFintrRATroN 
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A2.2  THE  WORLD  MODULE 


MODULE:  WORLD; 

SOURCE:  USA, JAP, k'RA, TWN, PHI . TAI ,  TSDWRD.  CTRURD: 
TARGET:  0 1  WORLD, 02UORLD: 

1  LISA  FILE  m  MAIL, 

2  USARCUMO)  RECORD, 

4  PROC.ID  FLD  (CHAR  101 .  /*  MAIL  ADDRESS  */ 

4  .'M«2, PX$2,  X$2,USAPY, IJSAY.IJSAR) 

ARE  FLD  (DEC  FLOAT ( 15)1: 

END .  USARC  ( T 1 =T=S  I  M.PD: 

t  ,'AP  FILE  CRG  MAIL. 

2  ,IAPRC(1:10)  RECORD, 

i  PROC.ID  FLD  (CHAR  10)-  /»  MAIL  ADDRESS  ♦  / 

4  ( M« 1 , PX$ 1 , X$1 , JAPPY , ..IAPY . .JAPR ) 

ARE  FLD  (DEC  FLOAT! 15) U 

end.jafrc(T)=t=sim_pd; 

t  TWN  FILE  ORG  MAIL, 

:  TWNRCddO)  RECORD, 

4  PROC.ID  FLD  (CHAR  10).  /*  MAIL  ADDRESS  ♦  / 

4  (M*3-PX$3.X$3,TWNPY,TWNY,TUNR) 

ARE  FLD  (DEC  FLOAT! t5)): 

ENO.TWNRiC;T)=T=SIM.PO: 

1  KRA  FILE  ORG  MAIL, 

2  KRARCddO)  RECORD. 

4  PROC.ID  FLD  (CHAR  10).  /#  MAIL  ADDRESS  *1 

4  (M*4,PX*4,X$4,KRAPY,KRAY,KRARI 
ARE  RD  (DEC  FLOAT!  15)): 

END. KRARC ( T ) =T=S I M.PD; 

1  PHI  FILE  ORG  MAIL, 

2  PHIRC(1:10)  RECORD, 

4  PROC.ID  FLD  (CHAR  10),  /*  MAIL  ADDRESS  *> 

4  (M$5,PX*5,X*5,PHIPY,PHIY.PHIR) 

ARE  FLD  (DEC  FL0AT(15>>: 

END.PHIRC(T)=T=SIM.?D: 


1  TAI  FILE  ORG  MAIL, 

2  TAIRC(l:lO)  RECORD, 

4  PROC.ID  FLD  (CHAR  10>.  /*  MAIL  ADCtRESS  ♦  / 

4  (M$/),PX*6,X«6,THIPY.THIY.TH1R) 

ARE  FLD  (DEC  FLOAT! 15) ): 

END.TAIRC(T)=T=SIM_PD: 

END. I2R(T)=T=SIM.PD: 

1  CTRWRO  FILE,  /»  THE  CONTROL  FILE  */ 

2  CR  RECORD, 

"  3  START .YR  FLD  (PIC  "0999'),  /*  STARTING  YEAR  OF  SIMULATION  */ 

3  LAG  FLD  (PIC  '9').  /#  LAG  FROM  the  starting  YEAR  */ 

3  SIM.PD  FLD  (Pic  99'),  /*  SIMi.n.ATION  PERIOD.  */ 

2  I21R  RECORD, 

3  HDH  FLD  (CHAR  319). 

2  12R(i:10)  RECORD-  LCCAL  HISTORICAL  DATABASE  ♦/ 

3  HYR  cLD  '(CHAR  4). 

3  (T$; 1 , x$22. x$33. X$44, <$55. X$G6. ALPHA, BETA71 , BFTA72. BETA73, BETA?*, BFTA7*. 


BET  A74 .  BET  A77 ,  PX$7 1 

ARE  FLO  (PIC'BB(IO)-AV.  (71AM: 


1  T30WRD  FILE,  /*  TIME  SERIES  DATA  FILE  */ 

2  TSR(  1 : 100)  GRP, 

3  HDR  RECORO, 

4  HDD  FLD  (CHAR  21). 

3  TR(IO)  RECORD, 

4  TS.DATA  FID  (PIC'BB<10)-vV.<7)P'); 

1  01  WORLD  FILE  kEY  IS  ADR  ORG  POST, 

/»  A  UNIFORM  FILE  FOR  SENDING  BACK  TO  MODULES  *■' 

2  016(1  MO)  GRP. 

3  Olft(i)  RECORD, 

4  ADR  FLD  (CHAR  14),  /*  MAILING  ADDRESSES  */ 

4  (OWT*,OPW*,PM«Z) 

ARE  FLD  (DEC  FLOAT! 15))) 

END . 0 10 ( T ) =T=SI M_PD ; 

!  INTX  FILE,  /*  INTEGRATED  FILE  BEOFRE  DISTRIBUTION  #/ 

2  IN2RUM0)  RECORD, 

3  (UT$,PWS,PM$t,PM$2.PM$3.PM$4,PM$5,PM$6> 

ARE  FLD  (DEC  FLOAT! 15)1: 

END. IN2R(T)=T=SIM_PD! 

( T , I , J I  SUBSCRIPT; 

1  02W0RLD  FILE,  /*  LOCAL  RESULTS  */ 

3  HO  RECORD, 

4  FHD  FLD  (CHAR  124), 

3  BLKO  RECORD, 

4  FO  FLD  (CHAR  80), 

3  GGRP  GRP, 

4  END_HD  RECORD, 

5  ENO.HDN  FLD  (CHAR  124), 

4  END.FR  RECORD, 

5  END.FF  FLD  (CHAR  :?0). 

4  NAMES  RECORD, 

5  NM1  FLD  (CHAR  124), 

4  BUM  RECORD, 

5  FI  FLD  (CHAR  SO), 

4  VALUESK 1: 10>  RECORD- 
5  YEAR1  FLD  (PIC  'Wl, 

5  ( X$3t .  <$51,  X$*l-  X$12>  X$32,  <$52-  X$l3) 

FLD  (PIC/6B(7)-PV.(6)9M, 

4  BLK11  RECORD, 

5  Ft l  FLD  (CHAR  80), 

4  NAMES2  RECORD, 

5  NM2  FLD  (CHAR  124). 

4  BLK2  RECORD, 

5  F2  FLD  (CHAR  80), 

4  VALUES2( 1: 10)  RECORD, 

5  YEAR2  FLD  (PIC  'W'), 

5  (X$53.  X$63,  X$34,  X$54,  <$A4,  X$35.  X$A5) 

FLD  <PIC'BB(7)-AV.<6>9'i. 

4  BLK22  RECORD, 

5  F22  FLD  (CHAR  80). 

4  NAME S3  RECORD, 

5  NM3  FLD  'CHAR  124). 

4  6LK3  RECORD, 

5  F3  FLD  (CHAR  80). 

4  VALUES3I1M0)  RECORD- 
5  YEAR3  FLD  (PIC 


5  (X11S.  X13S,  X14A.  mb'  X477.PU7S.  Xt2AI 
FID  (PIC' BB(7)-9V,  ( A)'5  ' ) . 

4  BLK33  RECORD, 

5  F33  F|_D  (CHAR  30 K 
4  N4MES4  RECORD, 

5  NM4  FLD  (CHAR  124). 

4  ELK 4  RECORD, 

5  F4  RD  (CHAR  30), 

4  VALIJES4<  l:  10)  RECORD, 

5  YEAR4  RD  (PIC  W), 

5  (X$7S.PX$75,X145.  X125,  X$15>  X*7‘5,PX*74) 

RD  (PIC'BB(71-9V.(S)9'), 

4  BLK44  RECORD. 

S  F44  FLD  (CHAR-  30), 

4  NAME5  RECORD, 
c  N*5  FLD  (CHAR  124). 

4  BLK5  RECORD- 
5  F5  FLD  (CHAR  30 S. 

4  VALL€S5(l:l0)  RECORD. 

5  YEAR5  FLD  (PIC  Wl, 

0  ( X124,  X*14,  X174.PX173.  X143.  X123.  X$73) 

FLD  <PIC'BB(7)-9V.(6)9'), 

4  BLK55  RECORD, 

5  F55  FLD  (CHAR  SO). 

4  NAMES  RECORD, 

5  NM6  FLD  (CHAR  1241, 

4  BLK6  RECORD, 

5  FA  RD  (CHAR  SO). 

4  VALUESSUMO)  RECORD. 

5  YEARS  FLD  (PIC  '9999'), 

5  (PXS72,  X162,  X«42,  X172,  X171,  X17.  PX171) 

RD  (PIC/BB(7)-'7V.(6)RM. 

4  BLK.SS  RECORD, 

5  FW>  FLD  (CHAR  30), 

4  NAME7  RECORD, 

5  NM7  FLD  (CHAR  124), 

4  BLK7  RECORD, 

5  F7  FLD  (CHAR  30). 

4  VALUES7 (1:10)  RECORD, 

0  YEAR7  FLD  (PIC  '««'), 

5  <X*41,  XS21,  X$17,  X127,  XS37,  X147.  X$57) 

RD  <PIC'BB(7)-9V.(S>9'), 

4  BLK77  RECORD, 

0  F77  FLD  (CHAR  30), 

4  NAMES  RECORD, 

5  NM3  FLD  (CHAR  124), 

4  BLK8  RECORD, 

5  F3  RD  (CHAR  30), 

4  VALUERS < 1 s 1 0 )  RECORD, 

5  YEARS  FLD  (PIC  'W'), 

■5  (X*S7,PX*77,  M$7.  PM17) 

FLD  (PIC'BB(7)-9V.(S)<)/). 

4  BLKSS  RECORD, 

“5  F33  FLD  (CHAR  33). 

4  EXD.HD  RECORD, 

5  EXD.HON  FLD  (CHAR  124), 

4  EXO.FR  RECORD, 

5  EXD.FF  FLD  (CHAR  30). 

4  NAMES  RECORD, 

5  NM9  FLD  (CHAR  124), 

4  BLK9  RECO  D, 

5  F9  FLD  (CHAR  30). 

4  VALUES9 < 1 : 1 0 )  RECORD, 

5  YEARS  FLD  (PIC  'ssssm, 

5  <0M$2  ,0PX*2  .0X12  .OUSAPY.fMlSAV.fllJSAR  ,rmi) 
FLD  (P!C'BB(7)-9V. (A)S' 


[ilil 


4  record. 

5  F»?  FLD  (WAR  30'  - 
4  NAME 10  RECORD. 

5  NM10  FLD  (CHAR  124). 


•>  6LK10  RECORD. 


5  F 10  FLD  (CHAR  '30'. 
VfilUES10<l:l0)  RECORD. 


5  FLD  (PIC  'W?'). 

?  (OPxil  .rixtl  .OJAPPV, 

OJAPV  .O..IAPR  .cm3  .0PX*3) 
FLD  (PIC'BB(7)-RV.  (A)g' ). 
BLK1010  RECORD. 

5  F1010  FLD  (CHAR  30). 

NAME  11  RECORD. 

5  NM11  FLD  (CHAR  124), 

BLK'Ul  RECORD. 

5  Fill  FLD  (CHAR  30). 

VALUES 11(1:10)  RECORD, 

5  YEAR  11  FLD  (PIC  'W'l, 


5  (0X$3  ,  OTWiF'Y.OTUNY  , OTUNR  ,0M*4 
FLD  (PIC'BB(7)-9V.(6)3'>. 

4  BLKlill  RECORD. 

5  Fill!  FLD  (CHAR  30), 


4  NAME12  RECORD, 

5  NM12  FLD  (CHAR  124), 

4  BLK12  RECORD, 

5  F 12  FLD  (CHAR  30). 

4  VALUES12(l:l0)  RECORD, 

5  YEAR  12  Fl  D  (PIC  W). 

5  (OKRAPY.QKRAY  . OKRAR  ,0M*5  , 
0PXS5  .0XS5  .OPHIPY) 

FLD  (PIC  BB(7)-9V.(6)P/), 

4  BLK1212  RECORD, 

0  F 1212  FLD  (CHAR  30). 

4  NAME13  RECORD, 

S  NM13  FLD  (CHAR  124). 

4  BLK13  RECORD, 

5  F13  FLD  (CHAR  30). 

4  VALUES13(1M0>  RECORD, 

5  YEAR  13  FLD  (PIC  'W), 

5  (OPHIY  .OPHIR  ,OWA  .OPX$A  .QX4A 
FLD  (PIC'BBm-ov.lAIR'), 

4  BLK1313  RECORD, 

5  F1313  FLD  (CHAR  SO), 

4  NAME 14  RECORD, 

5  NM14  FLD  (CHAR  124), 

4  BLK14  RECORD, 

5  F14  FLD  (CHAR  30), 

4  VAlUES14(l:iO)  RECORD- 
5  YEAR  14  FLD  (PIC  Wl, 

5  OTHIR 

FLD  (PIC'BB(7)-9V.(A)g''): 


.i1PX$4  .  0X44  1 


.OTHIPY.OTHIY) 


END_HDN=COPY( '  , 42 )  1 1  E  NDOGENOUS  VARIABLE  3': 
EXD_HDM=COPY( "  '.421 ! !  E  Y  0  0  E  N  0  U  S  VARIABLE  3  : 

(END.  DALLIES  1  ( T) ,  END.  VAUJE32I T ) ,  END. VALUE S3<  T ) .  END.  VALUES*  (T), 

END.  VALLE33' T ) .  END .  VAUJESA  ( T ) .  END .  VALUE37  ( T ) ,  END.  VALL€S3  ( T ) ) =T=R  im.FTi: 
( END. VALUES^ ( T ) . END . VALUES1 0 ( T ) . END . VALLES 1 1 ( T ) . END . VALLES 12(7). 

END . V ALOES 1 3 ( T ) . END . V ALIES 1 4 ( T ) ) = T=S I M  _P0 ; 


( YEAR  I ( T ) , YEAR2 ( T ) . YE AR3 <  T ) , YEAR* ( T ) . YEAR5 XT) , YEAR A ( 7 ) ■ YEAR7 ( T ) , YEARS ( T ) 
VEARg(T),YEAR10(T>,YEARll(T).YEARl2(T).YEAR13<T).YEAR14<T)l 
=START.YR+T: 

'F0.F1,F2.F3,F4,F3. FA.F7.F3.F1  1.f::,F33.F44.F^5.FAA.F77)=-' 
'Fg,FlO.Flll,F12.F13.F14,FftS.F'^.Fl010.FUi;.Fi212.F1313'- 
( EMD_FF . EKD_FF ) = ' 
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QTHIR=THIR: 

BLOCK  WRD:  MAX  ITER  IS  100.  RELATIVE  ERROR  IS  0.01: 

( IJSARC  >  JAPRC .  TWNRC >  PH  I RC ,  TA  IRC ,  KRARC )  =DEPENDS_QN 1 0 1 G ' 

INITIAL. M$t(T'=IF  T=1  THEN  TS_DATA(7,T) 

ELSE  M*l(T-n; 

INITIAL. Px*llT)=IF  T=l  THEN  TS.OATAIS.T) 

ELSE  PXiUT-1): 

INITIAL. XS1(T)=IF  T=1  THEN  TS.DATAIR.T) 

ELSE  Xtl(T-l): 

INITIAL.JAPPY(T)=IF  T=1  THEN  TS_DATA(10.T> 

ELSE  .JAPPY(T-l): 

INITIAL. JAPY(T)=IF  T=1  THEN  TS.DATAI 11, T) 

ELSE  JAPY(T-I); 

INITIAL. JAFR(T)=IF  T=1  THEN  TS.DATAdZ.T) 

ELSE  .JAPR(T-l); 

INITIAL.M«2(T)=IF  T=1  then  TS.DATAI1.T1 
ELSE  M$2(T-1); 

INITIAL. PX$2(T)=IF  T=1  THEN  TS.DATA(2,T) 

ELSE  PX*2(T-1 ) : 

INITIAL. X$2(T)=IF  T=1  THEN  TS.DATAI3.T) 

ELSE  X$2(T-1); 

INITIAL. USAPY(T)=IF  T=1  THEN  T$_DATA(4,T) 

ELSE  USAPY(T-l); 

INITIAL. USAY-'T)=IF  T=1  THEN  TS_DATA(5,T1 
ELSE  USAY(T-l); 

INITIAL. USAR(T)=IF  T=1  THEN  TS_DATA(6,T> 

ELSE  LtSAR(T-l)! 

INITIAL. M$3(T)=IF  T=1  THEN  TS.DATAI 13-T) 

ELSE  I1$3(T-1): 

INITIAL. PX13(T)=IF  T=1  THEN  T3.0ATA(14,T) 

ELSE  PX$3(T-1); 

INITIAL. X$3<T)=IF  T=1  THEN  TS_DATA(15.T) 
else  X*3(T-1); 

INITIAL. TWNPY(T)=IF  T=1  THEN  TS.DATAI 16. T) 

ELSE  TUNPY(T-l): 

INITIAL. TUNY(T)=IF  T=1  THEN  TS.DATAI 17, T) 

ELSE  TUNY ( T— 1  It 

INITIAL. TWNR(T)=IF  ”=1  THEN  TS.DATAI 13,T) 

ELSE  TUNR(T-l); 

INITIAL. M»4(T)=IF  T=!  THEN  TS.DATAI 19.T1 
ELSE  Mt4(T-l): 

INITIAL. PX*4(T)=IF  T=1  THEN  TS.DATAI 20- T) 

ELSE  PX44IT-1 ) ! 

INITIAL. X$4(T)=IF  T=1  THEN  TS.DATAI 21 . T ) 

ELSE  XJ4IT-1): 

INITIAL. KRAPY(T)=IF  T=1  THEN  TS.DATAI22.T) 

ELSE  KRAPYIT-l); 

INITIAL. KRAY I T ) = I F  T=1  THEN  TS.DATAI 23- T> 

ELSE  KRAY(T-l): 

INITIAL. KRAR(T)=IF  T=1  THEN  TS.DATAI 24, T> 

ELSE  KRARIT-t): 

INITIAL. M$5!T)=IF  T=l  THEN  TS.DATAI 25, T > 

ELSE  W5IT-1); 

INITIAL. PXtS(T)=IF  T=1  THEN  TS.DATAI 26, T) 

ELSE  PXt5(T-l): 

INITIAL. X*SITI=IF  T=1  THEN  TS.DATAI 27. T ) 

ELSE  XtSlT-lK 

INITIAL. PHIF'YITUIF  T=1  THEN  TS.DATAI PT. T) 

ELSE  PHIPVlT-i i: 
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INITIAL. PHIY(T)=IF  T=1  THEN  TS_DATA<29.T) 
ELSE  PHIY(T-l): 

INITIAL. PHIR(T)=IF  T=1  THEN  TSJjATA(30.T) 
ELSE  PHIR(T-l); 

INITIAL. MS6(T'=IF  T=i  THEN  TS.DATAI31.T) 
ELSE  M46IT-1); 

INITIAL. PX46(T)=IF  T=l  THEN  TS_DATA(32.T\ 
ELSE  PX*6(T-1H 

INITIAL. X$6(T)=IF  T=1  THEN  TS_DATA(33.T> 
ELSE  X*6(T-1): 

INITIAL.THIPY(T)=IF  T=i  THEN  TS_DATA(34,T> 
ELSE  THIPYIT-l)? 

INITIAL. THIY(T)=[F  T=1  THEN  TS_DATA<35,T> 
ELSE  THIYlT-l i: 

INITIAL. THIR(T)=IF  T=!  THEN  TS_DATA(36.T> 
ELSE  THlR(T-n: 


/*  THE  FOLLOWING  EQUATIONS  ARE  PROVIDED  BY  MR.  YASUDA.  LINk  PROJECT,  t«4  */ 
BLOCK  UORLBMD:  MAX  ITER  IS  100,  RELATIVE  ERROR  IS  0.01? 


X$31(T>  =  IF  T>LAG 

THEN  -95.3078  +  0.001490  *  JAPY(T)*1. 001*1000/357. 60 
+  0.3594  *  X*31(T-l) 

ELSE  TS_DATA(3?.T); 

X*51iT>  =  IF  T>LAG 

THEN  219.2138  +  0.001507  *  JAPY(T)*1. 001*1000.0/357.60 
-  127.4736  *  PX*5(T)/(.JAPPY(T)/1.001*357.60AJAPR(TH 
ELSE  TS_DATA(56»T); 

X46KT)  =  IF  T>LAG 

THEN  -10.5131  +  0.0005825  *  JAPY(T)*1. 001*1000.0/357.60 
+  0.5160  *  XS6KT-1) 

ELSE  TS.DATA(38,T); 

X*12(T!  =  IF  T>LAC- 

THEN  1386.7429  +  0.003833  ♦  U$AY(T)«0. 91:6*1000.0  ♦ 
0.7382  *  X*12(T-1) 

-  3132.5297  *  PX*l(T)/(USAPY(T)/0.R136/USAR(T)l 
ELSE  TS_BATA(39,T); 

X<32(T)  =  IF  T'.'LAO 

THEN  -59.5317  +  0.0005630  »  USAY(T) *0.91 36*1000.0  ♦ 
0.3706  *  X$32(T-1 ) 

-  299.5960  *  PXt3(T)/(USAPY(T)/0.9l36/H$AR(T)  l 
ELSE  TS_DATA(40.T): 

X$52(T)  =  IF  T>LAG 

THEN  169.3380  +  0.00002769  *  IJSAY(T>*0. 9196*1000.0  + 
0.7609  ♦  X$52(T-i) 

-  33.9859  *  PX45(T)/(IJSAPY(T)/0. 9136/1  ISAR(T) 1 
ELSE  TS.DATAI41.T): 

<*13IT)  =  IF  T3LAG 

THEN  29.3277  +  0.1295  *  TUNY (T 1*0.967/40. 10  * 

0.5790  »  X*l3(T-n 

-  986.9854  *  PX*1(T1*TUNR(T)/40,10 
ELSE  TS.DATA(42,T): 

X«53(T)  =  IF  T>laG 

THEN  10,2395  +  0,0(13610  *  TWNY(T)*0.^67/40. 10  + 

0.2533  *  X«53(T-1) 


-  15.3030  *  Plf$5(TUTWNR(Tl/4fi.lfl 
ELSE  TS-DATAI43.T); 

X*63(T)  =  IF  TMAG 

THEN  -16.4932  +  (T. 007639  *  TVJNYITUO. 967/40. 10 
ELSE  TSJ3ATA(57,T): 

X *34 ! T )  =  IF  T>LAG 

THEN  -28.0751  +  0.007392  *  KRAY{T)*1000.0/316.0 
ELSE  TS_BATA(58,T); 

X«54(T)  =  IF  T>LAG 

THEN  9.0581  ♦  0.002960  *  KRAY(T)*1000.0/?16.0  - 
11.5755  ♦  PX*5  ( T )  *6: RAR  <  T  Y  /3 1 6 . 0 
ELSE  TS.DATA(59,T): 

X$64(T)  =  IF  T>LAG 

THEN  -2.7504  +  0.00)05176  *  FRAYITHIOOO. 0/316.0  + 

1.0009  *  X464(T-1) 

ELSE  TS.DATA(44,T); 

X$35(T)  =  IF  T>LAG 

THEN  -12.3120  +  0.004234  *  PHIY(T)#l. 257/5.729  + 

0.7258  *  X*35(T-1) 

-  11.1044  *  PX*3(T)/  <PHIPY(T>/t. 257*5. 72?/PHIR(T)) 
ELSE  TS_0ATA<45,T): 

X465IT)  =  IF  TXAG 

THEN  8.1939  +  0.003371  *  PHIY(T>*1. 257/5. 729  - 
20.3589  *  PX$6(T) 

/  (PHIPY(T)  /  1. 257*5. 729/PHlR(T)l 
ELSE  TS_DATA(60.T): 

X$16(T)  =  IF  T>LAG 

THEN  372.8650  *  0.05599  *  THIY(T!«1. 135/20.9.30  + 

0.3090  *  X$16(T-1) 

-  429.7248  *  PX*1(T)/ 

(THIPY(T) /l. 135*20.93/THIR(T1 } 

ELSE  T3J3ATA(46,T) : 

X$36<T)  =  IF  T>Lft3 

THEN  4.9402  +  0.005841  *  THIY(T)*1. 135/20.930  - 
12.5023  *  PXJ3(T) 

/(THIPY(T)/1. 135*20. 93/THIR1T) 1 
ELSE  TS-DATA(61.T); 

X$46(T)  =  IF  T>LAG 

THEN  0.6136  ♦  0.001597  *  THIY(T)*1. 135/20.930  + 

0.2952  «  X446IT-1) 

-  5.3554  *  PX«4(Tl/(THIPY(T)/1.135*20.930/THIR(Tn 
ELSE  TS_DATA(47.T); 

X$56<T)  =  IF  T'LAG 

THEN  2.1872  +  0. 0003950  *  THIY(T!*t. 135/20,930  + 

0.4745  *  X*56(T-1) 

-  3.6961  *  PX*5(T)/fTHIPY(T)/l. 135*20. 93/THIRtTl) 
ELSE  TS.DATA(43,T): 

MTt(T)  =  IF  T3LA0 

THEN  X$1(T)  +  X*2(T)  +  X*3(T)  + 

X*4(T)  +  X$5(T)  +  X$6(T)  +  X17(T) 

ELSE  TS..DATA(62.Tl: 

X*77(T)  =  IF  T/LAO 

THEN  ALPHA < T X  *  UTt(T) 

ELSE  TS_DATA(63.T): 


PX*76(T>  =  IF  DLAG 

THEN  BETA76IT)  *  PW*(T1 
ELSE  TS_DATA(64,T>: 

PM*6!T)  =  IF  DLAG 

THEN  (PX$1(T)  «  X*16<T>  + 

PX*2(T>  *  X$26(T)  + 

PX«3(T)  *  X*36<T)  + 

PX*4(T)  *  X$46<T)  + 

PX$5(T)  »  X$56(T)  + 

PX*6<T)  *  X$66(T>  + 

PX$76(T)*  X$76(T>)  / 

(X$16(T1  +  X*26(T)  +  X*36(T)  +  X*46(T)  + 

X4561T)  +  X466(T)  +  X*76(T>) 

ELSE  TS_DATA(65,T); 

X426CT'  =  IF  DLAG 

THEN  401.3615  ♦  0.01471  «  THIY(T)*1. 135/20.730  + 

0.2443  *  X426(T-1> 

-  137.6322  *  PX*2(T)/PH$6IT1  - 

245.0900  *  PX$2( T )/( THIPY ( T >/ 1 . 135*20. 930/TH IR ( TU 
aSE  TS_DATA(49,T): 

X*76(T)  =  IF  T>LAG 

THEN  M$6(T)-(X*16(T)+X*26(T)+ 

X$36(T)+X*46(T)+X456<T)+T$66<T)) 

ELSE  TSJ3ATA(66.T)i 

PXJ75IT)  =  IF  T>LAG 

THEN  BETA75IT)  *  PW*(T) 

ELSE  TS_DATA(67,T): 

X*45(T)  =  IF  T>LAG 

THEN  2.0934  +  0.001067  *  PWIYID*!. 257/5. 729  - 
7.4456  *  PX$4(T)/Ptt$5(T) 
aSE  TS_DATA(63iTl ! 

X$'25(T)  =  IF  DLAG 

THEN  735.0191  +  0.01530  *  PHIY(T)*t. 257/5.729  + 

0.3397  *  X*25(T-1) 

-  361.9462  *  PX$2<T)/P**5(T)  - 

260.8525  *  PX$2(T)/(PHIPY(T)/t.257*5.729/PHIR(T)i 
aSE  TS.DATA(50,T); 

PM«5(T)  =  IF  T>LAG 

THEN  (PXtl(T)  *  X*15(T)  +  PX*2(D  *  X425ID  + 

PX*3<T)  *  X*35(T)  +  PX$4(T)  *  X$45(T1  + 

PX45IT)  «  X455IT)  +  PX*6(T)  *  X*65(D  + 

PXt75(T)*  X*75(D>  / 

(X*15(T)  +  X425IT)  +  X$35(T)  + 

X$45(T)  +  X4551T)  +  X465(T1  +  Xt75<T)> 

ELSE  TS.DATA(69,T)! 

X$15(T)  =  IF  DLAG 

THEN  933. 1553+0. 1030  *  PH1Y(T)*1. 257/5. 729+ 

0.3630  *  X$15(T-1) 

-  1223.3337  *  PX41(T)/PM45(D  - 
218.5203  *  PX$l(T)*PHIR(T)/5.729 

ELSE  TS.DATA(51,T): 

X*75(T)  =  IF  DLAG 

THEN  M45(T)  -  (Xtl5(T)  +  X425IT)  +  X435IT)  * 

X445(T)  +  X$55(T)  +  X465(T)) 

ELSE  TS.DATA(70.Tl: 


PX$74(T)  =  IF  DLAG 

THEN  BETA74IT)  ♦  py«(T) 

ELSE  TS.DATA(71,T); 

X*24(T>  =  IF  DLAG 

THEN  313.5893  +  0.07662  *  KUAY(T1*1000.0/316.0  - 
505.2523  *  PX$2(T)/PM44(T) 

-  266.6582  «  PX$2IT)/(KRAPY<T)*316.0/KRAR<T) ) 
ELSE  TS.DATA(72,T): 

PM4IT)  =  IF  DLAG 

THEN  (PXIIIT)  t  Xtl4(T)  ♦  PX*2(T)  *  X*24(T)  + 

PX$3(T)  *  X$34(T)  +  PX*4(T)  *  X*44(T1  + 

PX$5(T)  *  X$54(T)  +  PXJ6IT)  *  X464IT)  + 

PX$74(T!»  X$74(Tl )  / 

(X*14(T)  ♦  X*24(T)  +  X*34(T1  + 

X$44<T1  +  X$54(T)  +  X*64(T)  +  X*74(T1) 

ELSE  T3.DATA(73,T): 

X*14(T)  =  IF  T)L AC- 

THEN  3140.8171  +  0.1143  *  KRAY<T>#1000.0/?16.0  - 
3087.0086  ♦  PX$1(T)/PM*4(T) 

-  165.7276  *  PX$l(TV(KRAPY(T)t316.0/KRAR(Tn 
ELSE  TS_DATA<74,T): 

X$74(T)  =  IF  DLAG 

THEN  n*4(Tl  -  (X*14(T)  +  X$24(T)  +  X*34(T)  ♦ 
X*44(T)  ♦  X*54(T)  +  X464IT) ) 

ELSE  TS.DATAI75-T)? 

PX473IT)  =  IF  DLAG 

THEN  BETA73IT)  #  PU*(T) 

ELSE  TS.DATA(76,T); 

X*43(T)  =  IF  DLAG 

THEN  12.2308  +  0.004332  *  TWNY<T)t0.9670/40. 10  * 
0.3139  *  X«43(T-l) 

-  27.3673  *  PX$4<T)/PM$3(T) 

ELSE  TS_DATA(52,T); 

PIW3(T)  =  IF  DLAG 

THEN  (PX*1(T)  *  X$13(T)  + 

PX*2(T)  *  X*23(T)  + 

PX43IT)  *  X$33(T)  + 

PXi4(T)  #  X$43(T1  ♦ 

PX*5(T)  *  X«53<T)  + 

PX46IT)  *  X$63(T)  + 

PX$73(T)  *  X$73(T>)  / 

<X$13(T)  ♦  X$23(T)  ♦  X$33(T)  + 

X$43(T)  +  X$53(T1  +  X$63(T)  ♦  X*73(Tl) 

ELSE  TS_DATA(77-T); 

X*23(T1  =  IF  DLAG 

THEN  1144.7830  ♦  0.1027  *  T«NY(T)*0. 9670/40. 10  - 
1253.4655  *  PT*2(T)/PM$3(D 
ELSE  TS.DATA(7ft,T): 

X*73(T)  =  IF  DLAG 

THEN  «*3<T)  - 

f X413CT)  ♦  X*23<T)  +  X$33(T)  + 

X$43IT)  +  X*53<T)  +  X*63(T)) 

ELSE  TS.DATA(79.T1: 

PX472(T)=  IF  DLAG 

THEN  8ETA72IT)  *  PWt(T) 

ELSE  TS_DATA(80.D: 


X$62<T)  =  IF  T>LAG 

THEN  *2.0317  +  0. 0001 201  »  LISAY(T)*0.«13AO*1000.0  ♦ 
0.2423  »  X*62(T-1) 

-  113.0800  *  PXi6(T)/PtK2(Tl  - 

16.4208  *  PXS6IT)/(IJSAPY(T)/0.9136/USAR(T'  I 
ELSE  TS_DATA(53.T>: 

PH«2<T!  =  IF  T3LAG 

THEN  (PX*1(T)  *  X$12(T)  + 

PX*2(T)  »  X*22(T)  + 

PX*3<T)  »  X*32(T)  ♦ 

PX*4(T)  *  X*42(T>  ♦ 

PX*5(T)  #  X*52(T)  + 

PX*6(TI  *  X«62(T1  + 

PX*72(T>«  X$72(T)1  I 
(X*12(T)  +  X*22(T1  +  Xt32(T)  ♦ 

X*42(T)  +  X*52(T1  +  X*62(T)  +  X$72(TM 
ELSE  TS.DATAlSl.T't 

X*42(T)  =  IF  T>LAG 

THEN  -261.4902  +  0.001363  *  USAY(T)*0. *136*1000.0  ♦ 
0.4858  *  X«42(T-1) 

-  659.1006.  *  PXi4(Tl/PH$2(Tl  - 

170.9580  *  PX*4(T)/{tlSAPY(T)/0.«136/USAR(T)) 

ELSE  TS_DATA154,T1; 

X$72(T)  =  IF  T3LAG 

THEN  M21T1  -  (X*12(T)  ♦  X«22(T)  + 

X*32(Tl  +  Xt42(T)  ♦  X$52<T)  +  X$62(T) ) 

ELSE  TS_DATA(32’T): 

X*71(T)  =  IF  T'LAG 

THEN  H$1(T)  -  (X*11(T)  ♦  X$21(T)  ♦ 

X$31(T)  *  X«41(T)  +  X*5KT)  +  X*61(T>> 

ELSE  TS_BATAtS3,Tl; 

X*7(T)  =  IF  TOLAG 

THEN  X$71(T)  +  X*72(T)  ♦  X«73(T1  + 

X*74(T)  *  X*75(T>  +  X$76(T)  +X$77(T1 
ELSE  TSJATA(34,T); 

PW$(T)  =  IF  DLAG 

THEN  (PXtl(T)  *  X*1(T)  + 

PX$2(T)  *  X$2(T)  * 

PX*3(T1  *  X*31T1  * 

PX*4(T)  *  X*4(T)  + 

PX$5(T)  *  X$5(T)  + 

PX$6(T)  *  X«6(T)  ♦ 

PX*7(T)  *  XI7(T) )  / 

(X$1(T)  +  X$2(T)  +  X<3(T)  + 

X$4(T1  +  X*5(T)  +  X*6(T)  ♦  X$7(T) ) 

ELSE  T$_DATfi(35.T); 

PXS7KT)  =  IF  T'-LAG 

THEN  BETA7KT1  *  PW$(T> 

ELSE  TS_DATA(36.T): 

X*41  (T)  =  IF  TO  LAG 

THEN  210.7135  +  0.003307  *  ,!APY(T1*1. 001*1000.0/357.60 
♦  0. 2608  *  X44KT-1 1  -  5*9.0852  *  PX*4(T-l)/PHit(Tl 
ELSE  TS.DATAI55.Tl; 

PMtKT)  =  IF  TO  LAG 

THEN  (PXtl (T)  *  XtU(T)  + 

PX«21T)  *  X12HT)  * 

PX$3<T1  *  X$31(T1  * 


PX$4(T)  *  mi(T)  + 

PX$5(T)  *  X$51(T)  + 

PX$6(T)  »  XS6HT1  ♦ 

PX$71 (T)»  X$71(T>)  / 

(X$11(T)  +  X$21(TI  ♦  X$31<T)  ♦ 
x*4i<T)  ♦  x$5im  +  x$6kt>  +  X$71(T)> 

ELSE  TSJ3ATA(37.T); 

<$21  (T)  =  IF  DLAG 

THEN  3210.5934  ♦  0.02082  ♦  JAPY(T>»1. 001*1000.0/357.60 
-  3169.0851  *  PX$2(T)/Pmi(Tl 
ELSE  TS.DATA<83,T>: 

X417(T>  =  IF  DLAG 

THEN  X$1(T)  -  (X$11(T)  +  X$12(T)  ♦ 

X$13(T)  +  X$14(T1+X$15(THX$16(T)) 

ELSE  T$_DATA(89,T): 

XS27(T)  =  IF  DLAG 

THEN  X$2(T)  -  fX$21(T)  ♦  X$22IT>  + 

X$23(T>  ♦  X$24(T)+X$25(T)+X$26(T) ) 

ELSE  TS_DATA(90,T): 

X$37(T)  =  IF  DLAG 

THEN  X$3(T)  -  (X$31(T)  +  X$32(T)  + 

X$33(T)  +  X$34(T)+X$35(T)+X$36(T)) 

ELSE  TS.DATA<9l,T); 

X$47(T)  =  IF  T>LAG 

THEN  X$4(T)  -  (X$41(T1  +  X$42(T)  + 

X$43(T)  +  X$44(T)+X$45<T)+X$46<m 
ELSE  TS_DATA<92,T>; 

X$57(T)  =  IF  DLAG 

THEN  X$5(T)  -  (X$51(T)  +  X$52(T)  ♦ 

X$53(T)  ♦  X$54(T)+X$55(T)+X$56(T) ) 

ELSE  TS_0ATA<93,T); 

X$67(T)  =  IF  DLAG 

THEN  X$6(T)  -  (X$61(T)  +  X$62(T)  ♦ 

XS63IT)  ♦  X$64(T)+X$65(T)+X$66(T) ) 

ELSE  TS_DATA(94,T): 

PX$77(T)=  IF  DLAG 

THEN  8ETA77(T1  *  PW$(T1 
ELSE  T3.0ATA<95,T): 

«$7(T)  =  IF  DLAG 

THEN  X$17(T)  +  X$27(T)  ♦  X$37(T)  + 

X$47(T)  +  X$57(T)  +  X$67(THX$77(T) 

ELSE  TS.DATA(96,T); 

PM$7(T)  =  IF  DLAG 

THEN  (PXtl(T)  *  X$17(T)  + 

PX$2(T)  *  X$27(T)  + 

PX$3(T)  *  X$37(T)  + 

PX$4(T)  ♦  X$47(T)  + 

PX$5(T)  *  X$57(T1  ♦ 

PX$6(T)  *  X$67(T)  ♦ 

PX$77(T>*  X$77!T) )  / 

<X$17(T)  +  X$27(T)  +  X$37(T)  ♦ 

X$47(T)  +  X$57fT)  ♦  X$67(T)  ♦  X$77(TU 
ELSE  T3.DATA!97,T): 

END  WORLDNOi 

/*  DEFINE  ADDRESS  OF  THE  MESSAGE  TO  BE  SENT  */ 
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A2.3  THE  USA  MODULE 


MODULE:  USA: 

SOURCE:  HUSA.TSDUSA,  CTRUSA: 

TARGET:  01USA,02USA: 

1  II USA  FILE  ORG  MAIL.  /*  RECEIVED  FROM  THE  WORLD  MODULE  */ 

2  I1R(»)  RECORD, 

3  PROC.ID  FLD  (CHAR  14), 

3  (wt*,pw*,ph*2> 

ARE  FLD  (DEC  FLOAT (15)): 

END. I1R(T)=T=SIM_PD: 

t  TSDUSA  FILE. 

2  IR< 1 : 18)  GRP, 

3  HDR  RECORD, 

4  HDD  FLD  (CHAR  2D. 

3  TR(iO)  RECORD, 

4  TS_DATA  FLD  <PIC'BB<10)-9V.<7)9'): 

1  CTRUSA  FILE,  /*  THE  CONTROL  FILE  */ 

2  pp  REC^Di 

"  3  START.YR  FLD  (PIC  '9999'),  /*  STARTING  YEAR  OF  SIMULATION  */ 

3  LAG  FLD  (PIC  '9'),  /♦  LAG  FROM  THE  STARTING  YEAR  */ 

3  SIM.PD  FLD  (PIC  'PR'),  /♦  SIMULATION  PERIOD.  */ 

2  I21R  RECORD, 

3  DHD  FLD  (CHAR  10<?), 

2  I2R<»)  RECORD, 

3  HDYR  FLD  (CHAR  4), 

3  ( IJSAGP ,  XS*2 1 MS42 ,  D*JM ,  IJSAR ) 

ARE  FLD  <PIC'8B(10)-9V.  (7)9 ' ) ; 

1  01USA  FILE  ORG  MAIL, 

2  01R(*>  RECORD,  /«  SEND  TO  THE  WORLD  MODULE  */ 

3  MAIL.AOR  FLD  (CHAR  10), 

3  ( M$2, PX$2, X$2 1 USAPY , USAY » USAR ) 

ARE  FLD  (DEC  FLOAT! 15) )> 

MAIL_ADR=' I 1USAS" ? 

1  02USA  FILE.  /*  U3CAL  RESULTS  */ 

3  HD  RECORD, 

4  HFD  FLD  (CHAR  132), 

3  BLKO  RECORD, 

4  FO  RD  (CHAR  132), 

3  VALUES  GRP, 

4  ENO.HD  RECORD, 

5  END-HDD  FLD  (CHAR  124), 

4  BKKi  RECORD, 

5  BKF1  FLD  (CHAR  30), 

4  NAMES 1  RECORD, 

5  NM1  FLD  (CHAR  132), 

4  BLK1  RECORD, 

5  FI  FLD  (CHAR  132), 

4  VALUESKKIO)  RECORD, 

5  YEARt  FLD  (PIC  Wl, 

5  (0M*2, 0PXS2, 0**2, 01 JSAPY, OUSAY. IJSAM, IJSAPX ) 

ARE  FLD<PIC'BB(7)-9V.<6>9'), 

4  m2  RECORD, 

5  BKF2  FLD  (CHAR  30), 

4  NAMES2  RECORD, 

5  NM2  FLD  (CHAR  132), 

4  BLK2  RECORD, 

5  F2  FLD  (CHAR  132). 

4  VALUES2U:  10)  RECORD, 


5  (USAXtUSAItUSAC) 

ARE  aB(PIC'BB<7)-«V.<A)9'). 

4  BKK3  RECORD* 

5  BKF3  aD  (CHAR  SO), 

4  EXD.HD  RECORD. 

5  EXD.HDD  FID  (CHAR  124). 

4  EXD_B  RECORD, 

5  EXD.F  FID  (CHAR  124). 

4  NAHES3  RECORD, 

5  NM3  FID  (CHAR  132). 

4  BLK3  RECORD, 

5  F3  FLD  (CHAR  132), 

4  VALUES3 ( 1 s 10 )  RECORD. 

5  YEARS  aD  (PIC  '«W'), 

5  ( 0WT*,0PW$,0PM$2, OUSAR, GUSAGP, GXS$2,GMS«2 ) 

ARE  aD(PIC'BB(7)-RV.(6)9'), 

4  BKK4  RECORD, 

5  BKF4  FLD  (CHAR  SO), 

4  NAMES4  RECORD, 

5  NM4  FLD  (CHAR  132), 

4  BLK4  RECORD, 

5  F4  aD  (CHAR  132), 

4  VALUES4<1:10)  RECORD, 

5  YEAR4  FLD  (PIC  Wl, 

5  (ODUM) 

ARE  FLD(PIC/BB(7!-9V.(6)9/); 

END_HDB=COPY( '  ',42) !! 'ENDOGENOUS  VARIABLES': 

EXDJ(BD=COPY<'  ',42)1  !'E  X  0  0  E  N  0  U  S  V  A  R  I  A  B  L  E  S': 

( END. VALUES 1 ( T ) , END. VALUE$2(T ) , END. VALUES31 T ) , END. VALUES4 (T) ) =T=SIM.PD! 

QWT*=UT$: 

CfW»=PW»: 

0Pf1*2=FD$2: 

cm2=W2; 

0PX$2=PX$2: 

0X*2=«2? 

OUSAPY=USAPY? 

OUSAY=USAY? 

OUSAGWJSAGP? 

OXS*2=XS*25 

0MS$2=HS*2i 

OOWMMH 

ousar=ctrusa.usar; 

<  YEAR1 (T), YEAR2 (T), YEAR3 (T), YEAR4 (T) ) =$TART_YR+T : 

(F0,F1,F2,F3,F4,BKF1,BKF2,BKF3,BKF4.EXD.F)='  ': 

HaHXf'Y ( '  ',46) !  J 'LOCAL  SIMULATION  REPORT  FOR:  USA': 


NM1='YEAR 

H*2 

/  »  i  ✓ 
i  f 

PX*2 

i  i  .' 

x« 

/  1  »  ' 
i  i 

IJSAPY 

1  i  / 

USAY 

/!»/ 
i  i 

USAM 

i  i  / 

1  i 

I.ISAPX 

« 

NM2='YEAR 

USAX 

/II/ 
i  i 

USA  I 

l  i  / 
i  • 

USAC 

/  • 

♦ 

NM3='YEAR 

UT$ 

/II/ 
i  i 

PW$ 

1  I  / 
t  I 

PM$2 

/ll/ 
i  • 

USAP 

i  i 

USAGP 

/ll/ 

XS$2 

)  l  / 
t  < 

MSI2 

•'* 

NM4='YEAR 

DUM': 

T  SUBSCRIPT; 


212 


BLOCK  us:  MAX  ITER  IS  20.  RELATIVE  ERROR  IS  0.01? 

UR(T)=DEPENDS_QN(Q1R(T)); 

INITIAL. WT$(T)=IF  T«AG  THEN  TS_DATA(9,T) 

ELSE  WT$<T-tt: 

INITIAL. PU<(T)=IF  T<=LAG  THEN  TS_DATA< 10.T) 

ELSE  PW*(T-1): 

INITIAL. FM<2(T)=IF  T<=LAG  THEN  TS.DATAdl.TI 
ELSE  PM$2(T-1): 


/*  THE  FOLLOWING  EQUATIONS  ARE  PROVIDED  BY  MR.  YASUDA,  LINK  PROJECT.  1984  */ 
BLOCK  USAMO:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  O.Ot: 

M$2<T)  =  IF  TXAG 

THEN  -27696.3164  f  0.02479  *  USAY(T)*0. 9136*1000  + 

0.7377  #  M*2(T-1)  ♦ 

16213.6127  ♦  IJSAPY < T > .'0 . 91 36/RM$2 ( T 1  tCTRUSA . IJSAR ( T ) 
aSE  TS_DATA(6,T); 


USAM(T)  =  IF  TXAG 

T HEN  <M$2(T)  +  MS*2(T)>/  (0.391  »  1000.) 
aSE  TS_DATA(12,T): 

USAPY(T)  =  IF  TXAG 

THEN  0.03639  +  0.6478  «  USAY<T)/117l. 1  + 

0.2320  *  PM$2(T)/1. 121*CTRIJ$A.IJSAR(T) 
aSE  TS_DATA(13,T)‘, 

IJSAPX(T)  =  IF  TXAG 

THEN  0.03325  +  0.3617  t  IJSAPY(T)  +  0.6260  *  PW$(T) 
♦CTRUSA.  IJSAR  IT) /l.  128 
aSE  TSJ)ATA(14.T): 

PX$2(T)  =  IF  TXAG 

THEN  -0.007977  +  1.0014  #  USAPX(T)*CTRUSA.USAR(T)/0.931 
ELSE  TS_DATA(15,T); 

X$2(T)  =  IF  TXAG 

THEN  36598.1049  ♦  0.08361  *  WT$(T)  +  0.2392  *  X«2<T-1) 

-  32236.3591  *  PX$2(T)/PW*(T) 

ELSE  TS_DATA(7.T): 

IJSAX(T)  =  IF  TXAG 

THEN  (X$2(T)  +  XSI2IT))/  (9.31  *  1000.) 
aSE  TS.DATAU6.T): 

USAI(T)  =  IF  TXAG 

THEN  -33.6486  +  0.1879  *  USAY(T)  -  31.1877  ♦  DUM(T) 
aSE  TS.DATA(17,T): 

IJSAC(T)  =  IF  TO  LAG 

THEN  -22.0843  +  0.2736  *  USAY(T)  +  0.6127  t  ij$Af(T-n- 
9.4185  «  DUM(T) 
aSE  TS_DATA(8,T); 

USAYiT)  =  IF  TXAG 

THEN  USAC(T)  +  USAI(T)  +  USAGP(T)  +  IJSAX(T)  -  IJSAM(T) 
aSE  TS.DATA(IS.T); 


END  USAMDi 
END  US? 


A2 . 4  THE  JAPAN  MODULE 


MODULE:  JAPAN: 

SOURCE:  II JAP AN,  TSDJAPAN,  CTRJAPAN; 

TARGET:  0 1 JAPAN, 02 JAPAN! 

1  II JAPAN  FILE  ORG  MAIL,  /*  SENT  FROM  THE  WORLD  MODULE  */ 

2  I 1R( * )  RECORD, 

3  PROC.ID  FLD  (CHAR  14),  /*  ADDRESS  SENT  FROM  THE  WORLD  */ 
3  (WT*,PW4,PM$1) 

ARE  FLD  (DEC  FLOAT! 15)): 


END. I1R(T)=T=SIM_P0: 


1  CTRJAPAN  FILE,  /»  THE  CONTROL  CTLE  */ 

2  fiR  RECORD* 

‘  3  START _YR  FLD  (PIC  'W'),  /»  STARTING  YEAR  OF  SIMULATION  */ 

3  LAG  FLD  (PIC  "R">,  /#  LAG  FROM  THE  STARTING  YEAR  #/ 

3  SIM.PD  FLD  (PIC  "P9"),  /*  SIMULAT ION  PERIOD.  */ 

2  I21R  RECORD, 

3  DHD  FLD  (CHAR  109), 

2  I2R(*>  RECORD,  /*  LOCAL  HISTORICAL  DATABASE  */ 

3  HDYR  FLD  (CHAR  4), 

3  ( JAPGP,  XSSI ,  MS$  1 ,  DUfi,  JAPR ) 

ARE  FLD  (PIC'BB(10)-9V.(7W"); 

1  TSOJAPAN  FILE, 

2  IRC  1 : 18)  GRP, 

3  HDR  RECORD, 

4  HDD  FLD  (CHAR  21), 

3  TR(10)  RECORD, 

4  TS.DATA  aD  (PIC'BB<10)-9V.<7)R'); 


1  01 JAPAN  FILE  ORG  MAIL,  /*  SEND  TO  WORLD  MODULE  */ 

2  Q1R<*>  RECORD, 

3  MAIL.ADR  aD  (CHAR  10),  /*  GIVING  WORLD  MODULE  THE  RETURN  ADR  */ 

3  (M$l , PX$1 , X$1 , JAPPY , JAPY , JAPR ) 

ARE  FLD  (DEC  FLOAT! 15)): 

MAIL.ADR1 2 3 4 5'' 1 1  JAPANS": 

1  02JAPAN  FILE,  /*  LOCAL  RESULTS  */ 

3  HD  RECORD, 

4  HFD  FLD  (CHAR  132), 

3  BLKO  RECORD, 

4  FO  FLD  (CHAR  30), 

3  VALUES  GRP. 

4  END.HD  RECORD, 

5  END.HDD  aD  (CHAR  124), 

4  BKK1  RECORD, 

5  BKF1  FLD  (CHAR  SO), 

4  NAMES 1  RECORD, 

5  NM1  FLD  (CHAR  132), 

4  BLK1  RECORD, 

5  FI  FLD  (CHAR  132). 

4  VflLUESl ( 1 : 10)  RECORD, 

5  YEAR1  FLD  (PIC  'W'l, 

5  (Otttl , OPXS 1 , 0X$1 , OJAPPY , OJAPY ,  ,IAPM, JAP**  > 

ARE  aD(PIC'8B(7>-RV.  (*)■>'), 

4  m2  RECORD, 

5  6KF2  aD  (CHM  30). 

4  NAMES2  RECORD. 

5  NM2  FLD  (CHAR  132). 
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b*  ■ 

i- 


L 


II 

if 

i 


t 

l 


b  ■ 

l . 


r 

L 


•* 


»— 

t 


4  BLK2  RECORD. 

5  F2  FLD  (CHAR  132). 

4  VALlESDUMO)  RECORD- 
5  VEAR2  FLD  (PIC  'W9M, 

5  (JAPX.JAPI.JAPC) 

ARE  FLD(PIC'BB(7)-W.(6)9'), 

4  6KK3  RECORD. 

5  BKF3  FLD  (CHAR  80). 

4  EXDJHD  RECORD, 

5  EXD-HDD  FLD  (CHAR  124), 

4  £XD_B  RECORD, 

5  EXD.F  FLD  (CHAR  124). 

4  NAHES3  RECORD, 

5  NM3  FLD  (CHAR  132), 
a  BLK3  RECORD, 

5  F3  FLD  (CHAR  132). 

4  VALUES3US10)  RECORD, 

5  YEARS  FLD  (PIC  W), 

5  ( OUT$ , OPU$ , OPIK 1 , 0 J APR . 0 J APGP , 0X3* 1 , OHS* 1 > 
ARE  FLD(P!C'BBI7)-9V.(6>9'), 

4  BKK4  RECORD. 

5  BKF4  FLD  (CHAR  30), 

4  NAMES4  RECORD, 

5  NH4  FLD  (CHAR  132), 

4  BLK4  RECORD, 

5  F4  FLD  (CHAR  132), 

4  VALUES4( l s 10)  RECORD, 

5  YEAR4  FLD  (PIC  W). 

5  (ODUM) 

ARE  FU)(PIC'BB(7)-9V. <6)9'), 


END_HDD=COPY< /  ',42)1  !'E  NDOGENOUS 
EXO_HDD=COPY('  ',42)!!'E  X  0  G  E  N  0  U  S 
(END. VALUES1 (T), END. VALUES2 ( T ) , END. VALUES3 ( T ) 
QHT$=WT*! 

OPW$=P««; 

OPM$l=Pf»l! 

cmi=wii 

,TPX*l=PX4l? 


V  A  R  I  A  B  L  E  *3'! 

V  A  R  1  A  B  L  E  S'! 

, END . VALUES* ( Tl) =T=SI M_PD; 


OXii=xti; 

CUAPPY=JAPPY; 

ojapy=.japy; 

OJAPGP=JAPGP; 

oxs*i=xs$i; 

OMS»l=MS*l; 

odum=duh; 

jJAPR<TRJAPAN.JAPR; 


(YEAR1  (T) ,  YEAR2(T) ,  YEAR3(T! ,  YEAR4(T)  )=-START.YR+r; 
( FO, FI , F2. F3, F4, BKF1 , BKF2 , BKF3, BVF4, EXD.F )='  ' : 


HFO=COPY ( ' 

,45)!!'L0CAL  SIMULATION  REPORT  FOR:  JAPAN': 

NM1='YEAR 

M$1 

/  »  i  / 
i  i 

PX*1 

i  i  / 

X«1 

/ii/ 

JAPPV 

: ;  * 

JAPY 

/ll/ 

JAPM 

1 1  * 

.JAPPX 

NM2='YEAR 

JAPX 

/li/ 
i  i 

JAPI 

1  i  / 

JAPC 

/  • 

i 

NM3='YEAR 

WT$ 

/ll/ 
i  i 

pg* 

i  i  / 
i  i 

PM$1 

/ll/ 
i  i 

JAPR 

1  1  / 

<  i 

JAPOP 

/ll/ 

i  » 

XS*1 

i  • 

MS*1 

/  • 

NM4=YEAR 

DUM': 

T  SUBSCRIPT; 


Jh 


2ir, 


SLOCK  JAP:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  0.01: 

I1R(T)=DEPENDS_0N(O1R(T) ); 

INITIAL. WTJ(T)=IF  T<=LAG  THEN  TS_DATA(4,T) 

ELSE  WT*(T-1); 

INITIAL. PU*(T)=IF  T<=LAG  THEN  TS_DATA(5,T) 

ELSE  PW*(T-1); 

INITIAL. PM$1 (T)=IF  T<=LAG  THEN  TS_BATA(6,T) 

ELSE  PM$1!T-1): 

/» - THE  JAPAN  MODEL  (FROM:  YASUDA,  LINK  PRO,tECT - 

BLOCK  JAPANMD:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  0.01: 


M51 (T)  =  IF  t:>lao 

THEN  -2412.7034  +  0.08578  *  JAPY(T)*l. 001/357. 6*1000. 

+  0.1034  *  Mtt(T-t) 

ELSE  TS.DATAd.T): 


■JAPM(T)  =  IF  T5LAG 

THEN  <M*1(T)  +  MS$1(T) 1/1000./  (1.  /  357.6) 

ELSE  TS_DATA(7,T); 

JAPPY(T)  =  IF  T>LAG 

THEN  0.1437  +  0.5280  *  JAPY(T)/70613.3  + 

0.3490  »  PM$ 1 ( T 1 *CTR J AP AN . JAPR ( T 1 / 357 . 6 
ELSE  TS.DATA(8,TU 

■JAPF'X(T)  =  IF  TXAG 

THEN  0.2756  +  0.3126  ♦  JAPPY(T)  f 

0.4104  «  PUS < T 1 «CTR JAP AN . J APR! T W 357 . 6 
ELSE  TS_DATA(9,T): 

PX4KT1  =  IF  T3LA6 

TIEN  -0.04544  +  1.0691  *  .JAPPX1T1/CTRJAPAN.  JAPR<T>»357.6 
ELSE  TS_DATA(10,T); 

X$1(T)  =  IF  T/LAG 

THEN  9397.7623  >  0.06519  *  WTi(T)  0.2933  *  XtllT-1) 

-  15585.5870  »  PX$l(T)/PWt(T) 

ELSE  TS.DATA(2,T): 

OAPX(T)  =  IF  T>LA6 

THEN  (Xtl(T)  +  XS*KT)  1/1000./  (1.  /  357.6) 

ELSE  TS_DATA( 1 1, T): 

■JAP 1 1 T  >  =  IF  T3LAG 

THEN  -5141.2522  +  0.4528  *  JAPY(T)  -  3652.4761  *  OUMIT) 
ELSE  TS.DATA(12,T); 

JAPC(T)  =  IF  T3LAG 

THEN  2161.6489  +  0.2332  *  .lAPY(T)  +  0.5245  *  .lAPC(T-l) 
ELSE  TS.DATA(3,T): 

JAPY(T)  =  IF  TOLAS 

THEN  JAPC(T)  +  JAPI(T)  +  JAPGP(T)  +  JAPX(T)  -  JAPMfTi 
ELSE  TS_DATA( 13, T); 


END  JAPANMD: 
END  JAP: 


2  lf> 


A2 . 5  THE  TAIWAN  MODULE 
MODULE: TAIWAN: 

SOURCE:  I1TAIWAN.TSDTUN.  CTRTWN; 

TARGET:  01TAIWAN.02TAIUAN: 

1  I1TAIWAN  FILE  ORG  HAIL, 

2  I1R<*>  RECORD, 

3  PROC-ID  FLD  (CHAR  14), 

3  (WT*,PW$,PM$3) 

ARE  FLD  (DEC  FL0AT(15) ): 

END. I1R(T)=T=SIM_PD? 

1  TSDTWN  FILE, 

2  IR< IS  18)  GRP, 

3  HDR  RECORD, 

4  HDD  FLD  (CHAR  21). 

3  TR(IO)  RECORD, 

4  TS.DATA  FLD  <PIC'BB(tO)-9V.(7)9'l: 

1  CTRTWN  FILE,  /*  THE  CONTROL  FILE  */ 

2  CR  RECORD » 

‘  3  START.VR  FLD  (PIC  '9999'),  /*  STARTING  YEAR  OF  SIMULATION  */ 

3  LAG  FLD  (PIC  /9'),  /*  LAG  FROM  THE  STARTING  YEAR  »/ 

3  SIM. PD  FLD  (PIC  '99' >.  /♦  SIMULATION  PERIOD.  «/ 

2  121 R  RECORD. 

3  DHD  FLD  (CHAR  88). 

2  I2R<*)  RECORD,  /*  LOCAL  DATABASE  */ 

3  HDYR  FLD  (CHAR  4), 

3  <  TWNGP , X S*3 , MS*3 , TWNR  > 

ARE  FLD  (PIC'BB(10)-9V.(7)9')? 

1  01TA1UAN  FILE  ORG  MAIL, 

2  CUR( * )  RECORD, 

3  MAIL.ADR  FLD  (CHAR  10), 

3  <M$3,PX$3,X$3,TUNPY,TWNY,TWNR) 

ARE  FLD  (DEC  FLOAT! 15))! 

MAIL-ADR-'IITAIWANS') 

1  02T A I WAN  FILE,  /*  LOCAL  RESULTS  */ 

3  HD  RECORD, 

4  HFD  FLD  (CHAR  132), 

3  BLKO  RECORD, 

4  FO  FLD  (CHAR  30), 

3  VALUES  GRP, 

4  ENDJHD  RECORD, 

5  END-HDD  FLD  (CHAR  124), 

4  BKK1  RECORD, 

5  BKF1  FLD  (CHAR  SO), 

4  NAMES 1  RECORD, 

5  NM1  FLD  (CHAR  132), 

4  BLK1  RECORD, 

5  FI  FLD  (CHAR  132), 

4  VALUESKl:  10)  RECORD, 

5  YEAR1  FLD  (PIC  '9999'), 

5  <0M*3,GPX$3,0X$3,0TWNPY, OTUNY, TWNM, TWNPX ) 

ARE  FLD(PIC'BB(7)-9V.(6)9'), 

4  m2  RECORD, 

5  BKF2  FLD  'CHAR  30). 

4  NAMES2  RECORD, 

5  NM2  FLD  (CHAR  132), 

4  8LK2  RECORD, 

5  F2  FLD  (CHAR  132). 

4  VALUES2(l:lO)  RECORD, 


5  YEAR2  FID  (PIC  Wl, 

5  (TUNX,TUNI,TUNC) 

ARE  FLD(PIC'B8<7)-9V.(i>R'), 

4  BKK3  RECORD, 

5  BKF3  FLU  (CHAR  80), 

4  EXD.HD  RECORD. 

5  EXDJIDD  FID  (CHAR  124), 

4  EXD.B  RECORD, 

5  EXD.F  FLD  (CHAR  124), 

4  NAMES3  RECORD, 

5  NH3  FLD  (CHAR  132), 

4  BLK3  RECORD, 

5  F3  FLD  (CHAR  132), 

4  VALUES3( 1 : 10)  RECORD, 

5  YEAR3  FLD  (PIC  W). 

5  <OWT*,OPW*,OPM*3,OTWNR, OTUNGP, 0XS*3, 0MS*3) 
ARE  FLD(PIC'BB(7)-9V.(6)-?'): 


END_HDD=COPY( '  ',42)1  !'E  NDOGENOUS  VARIABLE  S'? 
EXD.HDD=COPY( '  ',42) ! ! 'E  X  0  6  E  N  0  U  S  VARIABLE  S'? 
<  END . VALUES 1(7), END. VALUES2 ( T ) , END . VALUES3 ( T ) ) =T=S I M_PD : 

QUT*=WT*i 

OPU*=PW»; 

0PM*3=Ft!*3? 

0M*3=M*3> 

QPX*3=PX*3: 

0X*3=<*3? 

OTUNPY=TUNPY; 

OTUNY=TWNY; 

OTUNGP=TUNGP’> 

0XS*3=XS*3! 

ons*3=HS*3; 

OTWNRCTRTWN.  TWNR; 

(YEARl(T), YEAR2 (T), YEAR3 ( T ) ) =START_YR+T: 


HFO=COPY(' 

'.45): ('LOCAL  SIMULATION  REPORT  FOR:  TAIWAN'; 

NMl-'YEAR 

M$3 

/II/ 
i  l 

F'X*3 

/ 

1  1  / 

X*3 

/  11/ 
i  ■ 

TWNPY 

• 

i  i  / 

TUNY 

/II/ 

TWNM 

f 

i  i  / 

TUNPX 

NM2-'YEAR 

TUNX 

/ii/ 

•  i 

TUN  I 

/ 

1  1  J 

TUNC 

/  • 

NM3='YEAR 

UT* 

/ii/ 

1 1 

PW* 

' 

l  i  / 

PM*3 

/ii/ 

TUNR 

1  I  / 

I  I 

TUNGP 

/ii/ 

XS*3 

i  I  y 
i  i 

MS*3 

/• 

T  SUBSCRIPT; 


BLOCK  TUN?  MAX  ITER  IS  40,  RELATIVE  ERROR  IS  0.01? 

I1R<T)=DEPENDS_0N(01R(T) )? 

INITIAL. WT*(T)=IF  T<=LAG  THEN  TS.DATA(4,T) 

ELSE  WTt(T-l)? 

INITIAL. PU*(T)=IF  T<=LAG  THEN  TS_DATA(5,T) 

ELSE  PU41T-1 ): 

INITIAL. P***3(T)=IF  TC-LAG  THEN  TS_DATA(4,T) 

ELSE  PM3(T-1): 


/*  THE  FOLLOWING  EQUATIONS  ARE  PROVIDED  BY  MR.  YASUDA.  LINK  PROJECT,  1*84  */ 
BLOCK  TAIUANMB:  MAX  ITER  IS  40.  RELATIVE  ERROR  ?S  0.01? 


M3(T)  =  IF  DLAG 

THEN  -286.7472  +  0.3144  *  TWNYi T)«0. 967/40. 1000000  ♦ 
0.5442  *  M*3(T-1) 

-  517.0132  ♦  PM$3(TUCTRT«N.TWNR(T)/40. 1000000 
ELSE  TS_DATA(1,T1? 

TUNII(T)  =  IF  DLAG 

THEN  (N$3(T)  +  NSt3(T))*  40.1/0.7611 
ELSE  TS-DATA(7.Tli 

TWNPY ( T ) =  IF  DLAG 

THEN  0.03387  +  0.2337  *  TUNY(T)/261558.0  + 

0.6626  *  PMt3 ( T ) / 1 . 037 *CTRTUN . TUNR ( T 1  /  40 , 1 
ELSE  TS.DATA(o.T); 

TWNPi(T)=  IF  DLAG 

THEN  0.1513  ♦  0.2715  *  TVWPYITI  + 

0.5853  *  PUt ( T ) / 1 , 044 tCTRTUN . TUNR ( T ) /40. 1 
ELSE  TS_DATA(7,T); 

PX$3(T)  =  IF  DLAG 

THEN  0.05012  +  0.7712  *  TUNPXm/0.7744/CTRTUN.TUNR(T>*40. 1 
ELSE  TS-DATA(lOiT); 

X$3(T)  =  IF  DLAG 

THEN  -23.1007  +  0.004035  *  UTt(T)  +  0.8766  *  X$3(T-1) 

-  637.1323  *  PX$3(T) 

ELSE  T3_DATA(2.T); 

TUNX(T)  =  IF  DLAG 

THEN  <X$3(T)  +  XSt3(T) 1*40.1/0.7744 
ELSE  TS.DATA(ll,Tl: 

TUNI(T)  =  IF  DLAG 

THEN  -23803.1810  *  0.3534  *  TWNY(T) 

ELSE  TS_DATA(12iT); 

TUNC(T)  =  IF  DLAG 

THEN  10145.7455  +  0.3071  ♦  TWY(T)  ♦  0.3876  *  TUNT(T-l) 

ELSE  TS_0ATA(3.Ti; 

TUNY(T)  =  IF  DLAG 

THEN  TUNC(T)  +  TUNI(T)  «•  TUNGP'T)  +  THNX(T)  -  TWNN(T) 

ELSE  TS_DATA(13.T); 

END  TAIUANMD; 

END  TUN! 
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A2 . 6  THE  KOREA  MODULE 


MODULE:  KOREA: 

SOURCE:  I  IKOREAi  TSDKGREA,  C'TRKRAi 
TARGET:  0 1 KOREA , 02K0RE A ? 

1  I1K0REA  FILE  ORG  MAIL. 

2  I 1R( * )  RECORD, 

3  PROC.ID  FLD  (CHAR  14), 

3  <UT*,PVtt,PM$4) 

ARE  FID  (DEC  FL0AT(15)>; 

END. I1R(T)=T=SIM_PD: 

1  TSDkOREA  FILE, 

2  IR(i:i3)  GRP, 

3  HDR  RECORD, 

4  HDD  FLD  (CHAR  21), 

3  TR( 10)  RECORD, 

4  TS.DATA  FLD  (PIC'BB(10)-9V. (7)9' )? 

1  CTRKRA  FILE,  /#  THE  CONTROL  FILE  */ 

2  CR  RECORD, 

3  START.YR  FLD  (PIC  W),  /#  STARTING  YEAR  OF  SIMULATION  */ 

3  LAC  FLD  (PIC  '9'),  /*  LAG  FROM  THE  STARTING  YEAR  ♦/ 

3  SIH_PD  FLD  (PIC  '99'),  /»  SIMULATION  PERIOD.  »/ 

2  I21R  RECORD, 

3  HDH  FLD  (CHAR  109), 

2  12Rt*>  RECORD,  /♦  LOCAL  DATABASE  */ 

3  HYR  FLD  (CHAR  4), 

3  ( KRAGP ,  XS44 ,  MSJ4 ,  DUN ,  KRAR ) 

ARE  FLD  (PIC'BB( 10I-9V. (7)9' ); 

1  OlKOREA  FILE  ORG  MAIL, 

2  UlR( * )  RECORD, 

3  MAIL-ADR  FLD  (CHAR  10), 

3  (M*4, PXM, X«4,KRAPY, KRAY, KRAR) 

ARE  FLD  (DEC  FLOAT) 15))? 

MAIL_ADR='  1 1K0REAS'  ? 

1  02K0REA  FILE,  /*  LOCAL  RESULTS  */ 

3  HD  RECORD, 

4  HFD  FLD  (CHAR  132), 

3  BLKO  RECORD, 

4  FO  FLD  (CHAR  30), 

3  VALLES  GRP, 

4  ENDJHD  RECORD, 

5  END.HOD  FLD  (CHAR  124), 

4  BKK1  RECORD, 

5  BKF1  FLD  (CHAR  30), 

4  NAMES  1  FECORD, 

5  NM1  FLD  (CHAR  132), 

4  BLK1  RECORD, 

5  FI  FLD  (CHAR  132), 

4  VALUES1  (1: 10)  RECORD, 

5  YEAR1  FLD  (PIC  '9999'), 

5  (0M*4, OPX*4,OM4,OKRAPY, QKRAY.KRAM.KRAPX ) 

ARE  FLD(PIC'BB(7)-9V.(6)9  ), 

4  BKK2  RECORD, 

5  BKF2  FLD  (CHAR  30), 

4  NAMES2  RECORD, 

5  NM2  FLD  (CHAR  132), 

4  BLK2  RECORD. 

5  F2  FLD  (CHAR  132), 

4  VAUJES2(l:lO)  RECORD. 
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5  YEAR2  FLD  (PIC  'W'l, 

5  (KRAX.KRAI.KRAC) 

ARE  FLD(PIC'B6(7)-9V.  <6)9'), 

4  BKK3  RECORD- 
5  BKF3  FLD  (CHAR  30), 

4  EXD.HD  RECORD, 

5  EXD.HDD  FLD  (CHAR  124), 

4  EXD_B  RECORD, 

5  EXD_F  FLD  (CHAR  124), 

4  NAMES3  RECORD, 

5  1*13  FLD  (CHAR  132), 

4  BUG  RECORD, 

5  F3  FLD  (CHAR  132), 

4  VALUES3ll:lO>  RECORD, 

5  YEAR3  FLD  (PIC  '9999'), 

5  ( OUT*,  0PW4 ,  CPM14 ,  OKRAR,  OKRAGP ,  0XS$4 ,  0MS$4 ) 
ARE  FLD(PIC'BB(7)-9V.  (&)^», 

4  BKX4  RECORD, 

5  BKF4  FLD  (CHAR  30), 

4  NAMES4  RE03RD, 

5  NW  FLD  (CHAR  132), 

4  8LK4  RECORD, 

5  F4  FLD  (CHAR  132), 

4  VALUES4< i: 10)  RECORD, 

5  YEAR4  FLD  (PIC  W), 

5  (ODLW) 

ARE  FLD(PIC/BB(7)-9V.(6)9/); 


END_HDB=CQPY( '  ',42) ! !  E  NDOGENGUS  VARIABLE  S': 
EXD_HDD=COPY  < '  ' ,  42 )  1 ! '  E  X  0  G  E  N  0  U  S  VARIABLE  S': 

(END. VALUES1 ( T) , END. VALUES2 ( T ) , END. VALUES3 ( T) , END. VALUES4 ( T 1 ) =T=SIM_PD 


OWT$=UT$; 

opw$=pw<; 

0PM$4=PMW; 

0M$4=f1$4; 

0PX$4=PX*4; 

0X*4=X*4! 

OKRAPY=KRAPY: 

OKRAY=KRAY; 

OKRAGP=KRAGP: 

0XS*4=XS«4: 

OI1S*4=flS*4; 

odum=oum; 

OKRAR=CTRKRA.KRAR; 


( YEAR1  ( T ) ,  YEAR2  (T),  YEAR3  (T),  YEAR4  (TO  =START  _ YR+T; 
(F0,F1,F2,F3,F4,8KF1,BKF2,BKF3,BKF4,EXD-F>='  ': 
HFD=COPY('  ,45)!! 'LOCAL  SIMULATION  REPORT  FOR:  KOREA': 


NM1='YEAR 

1  l 
\  l 

M*4  '!!' 

PX$4 

/ 

X$4  'I l' 

krapy 

/ 

l  l 

I  i 

KRAY  ' ! ! ' 

KRAM 

f 

i  l  t 
l  i 

KRAPX 

NM2-'YEAR 

KRAX  ' ! ! ' 

KRAI 

/ 

1  l  / 

KRAC  ': 

NM3='YEAR 

UT*  ' ! ! ' 

pu* 

l  l  / 
l  1 

PM44  '!!' 

KRAR 

/ 

l  l 

I  • 

KRAGP  '!!' 

MS*4 

XS*4 

NM4='YEAR 

DUM'; 

T  SUBSCRIPT! 

BLOCK  KRA:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  0.01 : 
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I1R(T)=[£PEND$_QN(01R(T) 1; 

INITIAL. WT$(T)=IF  T<=LAG  THEN  TS.BATA(4,T) 

ELSE  WT$(T-1 ); 

INITIAL. PW$(T)=IF  T<=LAG  THEN  TS_DATA(5,T> 

ELSE  PW*(T-1>; 

INITIAL. PM$4(T)=1F  T<=LAG  THEN  TS_DATA(6.T1 
ELSE  PtH4<T-l ) ; 

/*  THE  FOLLOWING  EQUATIONS  ARE  PROVIDED  BY  MR.  YASUOA,  LINK.  PROJECT,  1984  */ 
BLOCK  KOREAMD:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  O.Oli 
M«4(T)  =  IF  DLAG 

THEN  -1159.2639  +  (0.3239  *  KRAY ( T X *  1 000 > / 3 1 6 . OCWOOO  + 

(480.3403  *  KRAPY(T)/PM$4(T1 
*316.  0000000 )  /CTRKRA .  KRAR  ( T 1 
ELSE  TS_DATA(1,T); 

KRAM(T)  =  IF  DLAG 

THEN  (M$4(T)  +  MS$4(T) 1/1000.0  *  316.0 
ELSE  T3_0ATA(7,T): 

KRAPY  ( T )  =  IF  DLAG 

THEN  -0.2485  +  1.0527  «  KRAY(T)/2577.36  + 

(0.1906  *  PM*4(T)*CTRKRA.KRAR(T) 1/316.0 
ELSE  TS_DATA(8,T); 

KRAPX(T)=  IF  DLAG 

THEN  0.2991  +  0.25450  *  KRAPY(T)  + 

(0.4680  *  PW$(T)*CTRKRA.KRAR(T> 1/316.0 
ELSE  TS_DATA(9,TK 

PX$4(T)  =  IF  DLAG 

THEN  -0.07560  ♦  (1.0345  *  KRAPX(T)*316.0)/CTRKRA.KRAR(T) 
aSE  TS_DATA(10,T1* 

/*  *316  IS  MOVED  TO  BEFORE  DIVISION  */ 

X$4(T)  =  IF  DLAG 

THEN  462.5595  +  0.004031  «  WTt(T)  +  0.7485  *  X*4(T-H 
-  (1268.9005  *  PX$4(T) )/PVt$!T) 
aSE  TS_DATA(  2,  T 1  ? 

i/dav (T*  p  r\i  An 

THEN  (X$4(T)  +  XS$4(T) 1/1000.0  *  316.0 
ELSE  TSJDATAdi.T): 

KRAI(T)  =  IF  DLAG 

THEN  -225.8597  +  0.3314  *  KRAY(T) 

ELSE  TS_DATA(12.T); 

KRAC(T)  =  IF  DLAG 

THEN  38.6775  *  0.1374  *  KRAY ( T 1  +  0.7332  *  KRAC(T-l)  - 
115.1:301  ♦  DLM(T) 

ELSE  TS.DATAI3.T); 

KRAY(T)  =  IF  DLAG 

THEN  KRAC(T)  +  KRAI(T)  ♦  KRAGP(T)  ♦  KRAX(T)  -  KRAM(T1 
ELSE  TSJ)ATA!13.Tl; 

END  KOREAMD; 

END  KRA; 


A2.7  THE  PHILIPPINE  MODULE 


MODULE:  PHILIPPI: 

SOURCE:  I1PHIL.TSDPHIL.  CTRPHIL: 

TARGET:  01PHIL.02PHIL: 

1  I1PHIL  FILE  ORG  MAIL, 

2  I1R(*>  RECORD, 

3  PROC.ID  aD  (CHAR  14), 

3  (WT$,PN4,Pt«5) 

ARE  FLD  (DEC  FLOAT ( 15) ) i 

END. I1R(T)=T=SIM_PD; 

1  TSOPHIL  FILE, 

2  IR( 1 : 18)  GRP, 

3  HDR  RECORD, 

4  HDD  FLD  (CHAR  21), 

3  TR(IO)  RECORD, 

4  T5.DATA  FLD  (PIC'BBf 101-PV, (7)9' ): 


1  CTRPHIL  FILE,  /*  THE  CONTROL  FILE  */ 

2  CR  RECORD, 

3  START.YR  FLD  (PIC  'W),  /#  STARTING  YEAR  OF  SIMULATION  */ 

3  LAG  FLD  (PIC  "?').  /»  LAG  FROM  THE  STARTING  YEAR  */ 

3  SIM.PD  aD  (PIC  '99'),  /«  SIMULATION  PERIOD.  */ 

2  121R  record, 

3  DHD  FLD  (CHAR  SB), 

2  I2R(»)  RECORD,  /»  LOCAL  DATABASE  */ 

3  HYR  FLD  (CHAR  4), 

3  (PHIGP,XS$5,MS*5,PHIR) 

ARE  FLD  <PIC'BBU0)-9V.(719'U 

1  OIPHIL  FILE  ORG  MAIL, 

2  01R(«)  RECORD, 

3  MAIL-ADR  aD  (CHAR  10), 

3  <M$5,PX$5,X$5,PHIPY,PHIY,PHIR) 

ARE  aD  (DEC  FLOAT!  15)) 5 

MAIL_A0R='I1PHILS'? 

1  02PHIL  FILE,  /*  LOCAL  RESULTS  #/ 

3  HD  RECORD, 

4  HFD  FLD  (CHAR  132), 

3  BLKO  RECORD, 

4  FO  aD  (CHAR  80), 

3  VALUES  GRP, 

4  ENO.HD  RECORD, 

5  END.HDD  aD  (CHAR  124), 

4  BKK1  RECORD, 

5  BKF1  aD  (CHAR  80), 

4  NAMES 1  RECORD, 

5  NM1  FLD  (CHAR  132), 

4  BLK1  RECORD , 

5  FI  aD  (CHAR  132), 

4  VALUES! (t: 10)  RECORD, 

5  YEAR1  aD  (PIC  W), 

5  (0M*5,0PXi5,0X$5,0PHIPY,0PHIY,PHIM.PHIPX» 

ARE  aD(PIC'B8(7)-9V.  (6)9'), 

4  BKK2  RECORD, 

5  BKF2  FLD  (CHAR  80), 

4  NAMES2  RECORD, 

5  NM2  FLD  (CHAR  132), 

4  BLK2  RECORD, 

5  F2  aD  (CHAR  132), 


4  VALUES2< 1 : 10)  RECORD, 

5  YEAR2  FID  (PIC  '9999), 

5  (PHIXiPHlIiPHIC) 

ARE  FLD(PIC'BB(7)-9V.(6)9‘), 

4  8KK3  RECORD, 

5  BKF3  FID  (CHAR  80), 

4  EXD.HD  RECORD, 

5  EXD_HDD  FID  (CHAR  124), 

4  EXD.B  RECORD, 

5  EXD.F  FLO  (CHAR  124), 

4  NAMES3  RECORD, 

5  NN3  FLD  (CHAR  132), 

4  BLK3  RECORD, 

5  F3  FLD  (CHAR  132), 

4  VALUES3( 1 : 10)  RECORD, 

5  YEARS  FLD  (PIC  '9W'), 

5  (OUT*,Om,OPM$5,OPHIR,OPHIGP,OX$$5.nMS«5) 

ARE  FLD<PIC'BB<7)-9V.(fc>9'); 

END_HDD=COPY  ( '  ',42)1  !'E  MDOGENOUS  V  A  R  I  A  B  L  E  S'! 

EXB_HDD=COPY ( '  /,42)!!'E  X  0  G  E  N  0  U  S  V  A  R  I  A  B  L  E  S'! 

( END.  VALUES  HT),  END.  VALUES2IT),  END.  VALUES3(T)  )=T=SIN_PD; 

0WT*=WT*5 

OPW*=PH*i 

0PM$5=Pt1$5; 

0W5=M$5! 

0PX$5=PX$5; 

0X$5=X*5; 

OPHIPY=PHIPY; 

0PHIY=PHIY5 

OPHIGP=PHIGP! 

0XS*5=XS*55 

0HSt5=HS$5; 

OPHIR*CTRPHIL.PHIR; 


(YEARKT),  YEAR2(T) ,  YEAR3XT)  )=START_YR+T! 
(F0,F1,F2,F3,BKF1,BKF2,BKF3,EXD_F)=/ 


HFD=COPY  ( ' 

',45)1! 'LOCAL  SIMULATION  REPORT  FOR:  PHILIPPINE': 

NM1='YEAR 

IH5 

/II/ 
i  i 

PX45 

i  1  ✓ 
i  1 

X*5 

/II  / 
i  i 

PHIPY 

i  1  / 
i  i 

PHIY 

/II/ 

PHIH 

»  1  / 

>  t 

PHIPX 

/  • 

1 

NM2=/YEAR 

PHI  X 

/li/ 
i  1 

PHI  I 

1  l  / 

I  l 

PHIC 

/  • 

NK3='YEAR 

WT* 

/li/ 

Pl« 

1  1  / 
l  l 

PW5 

/ll/ 

PHIR 

1  l  / 
l  1 

PHIGP 

/II/ 

XS*5 

<  l  / 
l  i 

MS*5 

/  • 

i 

T  SUBSCRIPT; 

BLOCK  PHI:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  0.01; 

IlR(T)=OEPENDS_ON(01R<T))i 

INITIAL. WT$(T)=IF  T«AG  THEN  TS.DATA(4,T) 

ELSE  MT*(T-1)5 

INITIAL. PW*<  T)=IF  T<=LAG  THEN  TS_DATA(5,T) 

ELSE  PW(T-l): 

INITIAL. P!H5(T)=IF  TOLAG  THEN  TS.DATA(A.T) 

ELSE  PM5(T-t): 

/*  THE  FOLLOWING  EQUATIONS  ARE  PROVIDED  BY  HR.  YASUDA,  LINK  PROJECT,  1084  ♦/ 


BLOCK  PHILIP:  MAX  ITER  IS  20,  RELATIVE  ERROR  IS  0.01? 

H$5(T)  =  IF  T>LAG 

THEN  -491.7211  +  0.1231  ♦  PHIY(T>*1.257 
/5.7290  +  0.5040  ♦  M*5(T-1) 

+  253.14210  *  PHIPY(T)/1,2570 
/FtK5 I T ) *5. 7290/CTRPHIL. PHIRf T ) 

ELSE  TS.DATA(LT); 

PHIM(T)  =  IF  T>LAG 

THEN  (M$5(T)  +  MS$5(T))*5. 729/1. 586 
ELSE  TS_DATA(7,T): 

PHIPY(T)=  IF  T>LAO 

THEN  0.1296  ♦  0.3945  *  PHIY(T)/29515.0  + 

0.4552  *  PM$5<T)/0.9140  *CTRPHIL.PHIR(T)/3.9 
ELSE  TS_DATA(8,T): 

PHIPX(T)=  IF  T>LAG 

THEN  -0.75110  +  1.8239  »  PHIPY(T) 

ELSE  TS_BATA(9,T)i 

PX$5(T)  =  IF  DLAG 

THEN  -0.02338  +  1.0404  *  PHIPX(T)/1.757/CTRPHIL.PHIR(T)*5.72<>0 
ELSE  TS_DATA(10,T)i 

X*5(T)  =  IF  DLAG 

THEN  1006.1559  +  0.001548  *  UT$(T)  +  0.3555  *  X*5(T-1) 

-  816.6783000  #  PX$5(T)/PW*(T) 

ELSE  TS_DATA(2,T); 

PHIX(T)  =  IF  T>LAG 

THEN  (X*5(T)  +  XS$5<T) 1*5.729/1.757 
ELSE  TS-DATA(ll.T); 

PHII(T)  =  IF  DLAG 

THEN  -3244.7515  +  0.3101  *  PHIY(T) 

ELSE  TS_DATA(12,T): 

PHIC(T)  =  IF  DLAG 

THEN  692.4862  +  0.08436  *  PHIYiT)  ♦  0.3906  *  PHIC(T-l) 

ELSE  TS.DATA(3,T); 

PHIY(T)  =  IF  DLAG 

THEN  PHIC(T)  +  PHII(T)  +  PHIGP(T)  +  PHIX(T)  -  PHIM(T) 

ELSE  TS_DATA(  13, T); 

END  PHILMD; 

END  PHI! 


A2.8  THE  THAILAND  MODULE 


MODULE:  THAILAND; 

SOURCE:  I 1THAI , TSDTHAI »  CTRTHl; 

TARGET:  01THAI.Q2THAI; 

t  I1THAI  FILE  ORG  MAIL, 

2  I1RI*)  RECORD, 

3  PROC.ID  FLD  (CHAR  14), 

3  (UT*,PW*,Pm6) 

ARE  FLD  (DEC  FLOAT* 15) >: 

EN0,I1R<T)=T=3IM_PD; 

1  T'SDTHAI  FILE, 

2  TR( 1 : 18)  GRP, 

3  HDR  RECORD, 

4  HDD  FLD  (CHAR  21), 

3  TR(10)  RECORD, 

4  TS.BATA  FID  (PIC'BBl  10)-9V.  <7)9'U 

1  CTRTHl  FILE,  /*  THE  CONTROL  FILE  */ 

2  CR  RECORD, 

3  START.YR  FLD  (PIC  W),  /#  STARTING  YEAR  OF  SIMULATION  */ 

3  LAG  RD  (PIC  '9'),  /♦  LAC;  FROM  THE  STARTING  YEAR  */ 

3  SIM.PD  FLD  (PIC  '99') ,  /*  SIMULATION  PERIOD.  */ 

2  I21r  record, 

3  DHD  RD  (CHAR  38), 

2  I2R(*»  RECORD, 

3  HYR  FLD  (CHAR  4), 

3  (THIGP,XS*6,MS*C>,THIR) 

ARE  RD  (PIC'BBUO-RV.mR"); 

1  OITHAI  FILE  ORG  MAIL,  /*  SEND  TO  THE  WORLD  MODULE  */ 

2  G1R<*)  RECORD, 

3  MAIL. ADR  RD  (CHAR  10), 

3  (M«,,Pm,m,THIPY,THIY,THIR) 

ARE  FU)  (DEC  FLOAT! 15)); 

MAIL_AOR='IlTHAI$'; 

1  02THAI  FILE,  /«  LOCAL  RESULTS  */ 

3  HD  RECORD, 

4  HFD  FLD  (CHAR  132), 

3  BLKO  RECORD, 

4  FO  RD  (CHAR  80), 

3  VALUES  GRP, 

4  ENO-HD  RECORD, 

5  END.HDO  FLD  (CHAR  124). 

4  BKK1  RECORD, 

5  9KF1  RD  (CHAR  80). 

4  NAMESt  RECORD, 

5  Ifll  FLD  (CHAR  132). 

4  BLK1  RECORD, 

5  FI  RD  (CHAR  132), 

4  VALUESKIRO)  RECORD, 

5  YEAR1  RD  (PIC  '9999'), 

5  (Cft*6,0Pm,0m,0THIPY,0THIY,THIM,THIPX) 

ARE  FLD(PIC'BB(7)-9V. (4)9' ) , 

4  BKK2  RECORD, 

5  BKF2  FLD  (CHAR  SO), 

4  NAMES2  RECORD, 

5  NM2  RD  (CHAR  132). 

4  BLK2  RECORD, 

5  F2  RD  (CHAR  132). 

4  VALUE32(l:lO>  RECORD, 


5  YEAR2  FID  (PIC  W), 

5  <  THIX *  THI I • THIC) 

ARE  FLD(PIC'BB(7)-W.(6)9-'), 

4  BKK3  RECORD, 

5  BKF3  FID  (CHAR  80), 

4  EXD.HD  RECORD, 

5  EXD.HDD  FID  (CHAR  124), 

4  EXD.B  RECORD, 

5  EXD.F  FU)  (CHAR  124), 

4  NAHES3  RECORD, 

5  NN3  aD  (CHAR  132). 

4  BLK3  REODRD, 

5  F3  aO  (CHAR  132), 

4  VALUES31 1:10)  RECC’-'D, 

5  YEARS  FLD  (PIC  Wl, 
c  ( ONT$,GPW$,OPM$6, OTHIR, OTHIOP, 0XS*6,0MS«> ) 

ARE  FLD(PIC/BB(7)-9V.(6)9'>; 

ENO_HDD=COPY('  ',42) ! !'E  N  D  0  G  E  N  0  IJ  S  VARIABLE  V': 

EXD_HDD=COPY ( /  ',42>::'E  X  0  G  E  N  0  U  S  V  A  R  I  A  B  L  E  S'! 

( END . VALUES 1 ( T ) , END . VALUES2  <  T ) , END . V ALUES3 ( T ) ) =T=S I M_PD  5 

OUT$=UT$; 

opw$=pw$; 

0PH*6=PH$6! 

cm6=n$6; 

0PX$6=P)S; 

ox$6=x*6; 

othipy=thipy: 

othiy=thiy; 

OTHIGP=THIijP* 

0XS$6=XS$6; 

0fts$6=ns$6; 

othirctrthi.thir; 

( YEAR1 (T) , YEAR2(T) , YEARS! T) )=START.YR+T; 

(F0,F1,F2>F3»BKF1,BKF2,BKF3>EXD_F)='  '? 

HFD=COPY('  ',45) 1 1 "LOCAL  SIMULATION  REPORT  FOR:  THAILAND': 

NM1=YEAR  M*6  '!!'  PX*6 

!!'  X*6  '!!'  THIPY 

!!'  THIY  '!!'  THIN 

I!'  THIPX 

NM2='YEAR  THIX  '!!'  THII 

thic 

NM3='YEAR  WTt  'll'  PW* 

!!'  Pm  'I!'  THIR 

!!'  THIGP  '!!'  XS*6 

! ! '  MS$6 

T  SUBSCRIPT; 

BLOCK  THI:  MAX  ITER  IS  40,  RaATIVE  ERROR  IS  0.01: 

I 1R(T)=DEPENDS_ON(01R(T) ); 

INITIAL. WT$(T)=IF  T<=LAG  THEN  TS.DATA(4,T) 
aSE  WTt(T-l); 

INITIAL. PW$(T)=IF  T<=LA6  THEN  TS_DATA(5,Tt 
ELSE  PW$(T-1); 

INITIAL. PM$6(T)=IF  T<=LAG  THEN  TS_DATA(t,T) 

ELSE  PNt6(T-l); 

/*  THE  FOLLOWING  EQUATIONS  ARE  PROVIDED  BY  HR.  YASUBA,  LINK  PROJECT.  19R4  */ 

BLOCK  THAIMD:  HAX  ITER  IS  40,  RaATIVE  ERROR  IS  0.01: 


2? 


M6(T>  =  if  t;  LAG 

THEN -820.4688  ♦  0.1252  *  THIYlTUl.l  0.3350  *  M6(T-1  ’ 

♦  763.0320  «  THIPY(T) /l. 135 
/Fm<T)/CTRTHI.THIR<T)*20.‘?30 
ELSE  T5.QATAU.TK 

THIH(T)  =  IF  T>IAG 

THEN  (M$6(T)  +  HS*6(T) >*20.93/1.08 
ELSE  TS_DATA(7.TK 

THIPY(T)=  IF  T>lAG 

THEN  0.4292  +  0.07972  *  THIY(T)/6379?.0  ♦ 

0.4995  ♦  PtHA ( T )  /fi . P7*CTRTH I .  TH1 R ( T )  / ;o .  S4 
ELSE  TS.0ATAC3.TK 

thifx(t>=  if  t:lag 

THEN  -0.2305  ♦  A.S310  «  TWIPYfT'  * 

0.6188  *  PW4 ( T l / 0 . 973*TTRTH I . TM I R ( T ) / 20 . 34 
ELSE  TS.DATACV.TK 

?X*6(T)  =  IF  T>LAG 

THEN  -0.06976  ♦  1.0885  ♦  THIPX  ( T  V 1 .016/8 TRTHI . THIR ( t i  ♦2u,  93 
ELSE  TS.DATAU0.TK 

X$6(T)  =  IF  TXAG 

THEN  567.0480  ♦  0.0009513  *  WT*(T)  ♦  0.5164  ♦  X«6<T-;i 
-  416.5699  *  PX$6<T)/PW4lT> 

ELSE  TS_DATA(2.TK 

THIX(T)  =  IF  T>LA6 

THEN  (X*6(T)  ♦  XS*6(T) 1*20.93/1.016 
ELSE  TSJATAUl.TK 

THII(T)  =  IF  TOLAG 

THEN  -3871.7198  *  0.2747  *  THIY(T) 

ELSE  TS_DATA( 12»T) * 

THIC(T)  =  IF  T>LAG 

THEN  2903.0806  +  0.2609  *  THIY(T)  +  0.6197  *  THICU-l) 

ELSE  TS_DATA<3,T); 

THIY(T)  =  IF  TIM 

THEN  THIC(T)  +  THII(T)  t  THIGP(T)  +  THIX(T)  -  THIIIITl 
ELSE  TS_DATA(  13.TK 

END  THAIMO* 

END  THI; 
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A2.10  EXECUTION  STATISTICS 


SYS9SYSDEVICE:  CSHI 1 JAPAN. ACTl 2 
MODULE!  JAPAN 


Accounting  inf "rmetion: 

Buffered  I/O  count!  294 

Direct  I/O  count!  S3 

Pese  f«u)t»i  737 

EUrsed  CPU  time!  O  00»00»2a.  13 


SYSSSYSDEV I CE I CSHI IKOREA. ACTl 2 
MODULE!  KOREA 


S YS*S YSDEV ICE«  CSHI 3PHILIPPI . ACTl 2 
MODULE!  PHILIPPI 


SYS9SYSDEV I CE i C  3H II TA I MAN . ACT I  2 
MODULE!  TAIWAN 


Account i ns  information! 

Buffered  I/O  count!  290 

Direct  I/O  count!  140 

Psse  faultii  663 

El  arsed  CPU  time!  0  00i00i2t.!9 


SYSSSYSDEV ICE! CSHI 3 THAILAND. ACTl 2 
MODULE:  THAILAND 


Accountins  information! 

Buffered  I/O  count!  290 

Direct  I/O  count!  87 

Pase  faults!  633 

Elapsed  CPU  time!  0  OOIOOI26. 11 


SYS9SYSDEV I CE i C  SH II USA . ACT I  2 
MODULE:  USA 


Peak  workins  set  size!  234 
Peak  rase  file  size!  4183 

Mounted  volumes:  0 

Elapsed  time!  O  00:07:47.87 


Accountins  information! 

Buffered  I/O  count!  294 

Direct  I/O  count!  74 

Pase  faults!  631 

Elapsed  CPU  time!  0  00:00:16.13 


Peak  workins  set  size!  282 
Peak  pase  file  size:  4183 

Mounted  volumes:  0 

Elapsed  time:  O  0d07:  39.70 


Accountins  information! 

Buffered  I/O  count:  290 

Direct  I/O  count!  78 

Pase  faults'  664 

Elapsed  CPU  time!  O  00:00120.40 


Peak  workins  set  size:  287 

Peak  pase  file  size!  3770 

Mounted  volumes!  O 

Elapsed  time!  O  00:07:36.33 


Peak  workins  set  size:  287 

Peak  rase  file  size!  3770 

Mounted  volumes!  0 

Elapsed  time!  0  00:07:38.1° 


Peak  workins  set  size:  286 

Peak  ease  file  size:  7770 

Mounted  volumes*  O 

Elapsed  time*  0  00«07:36. 16 


Accountins  information* 

Buf farad  I/O  count* 

20^ 

Paak  workins  sat  siza* 

281 

Dir act  I/O  count* 

7a 

Pa ak  rasa  fila  siza* 

4  1 87 

Pasa  faul ts* 

660 

Mountad  vo lumas* 

o 

Elaasad  CPU  tima* 

0  00*00*18.29 

Elaasad  tima*  0  00 

s  07 :  4  t 

SYS4SYSDEVICE*  CSHI ] WORLD. ACT*  ? 
MODULE*  WORLD 


Accounting  information* 

Buffered  I/O  count*  1209 

Direct  I/O  count*  130 

Paaa  faults*  1361 

El  aasad  CPU  tima*  0  00*02*44. 77 


Paak  tuor-kins  sat  siza*  46P 
Paak  aa«a  fila  siza*  414 

Mountad  vo lumas*  0 

Elaasad  tima*  0  00*07*47,73 


APPENDIX  B 

EBNP  OP  CONCURRENT  MODEL 


<modelspecipication>s;-c<modelbodys™ts>  /CLRERRP/  ]* 

/STMTFL/  <  MODELSPEC I F I CAT! ON  >  . 

(MO0ELBODYSTMTS  > ! /E( 80 )/ 

MODULE  (MODULENAMESTMT) 

| SOURCE  (SOURCEFILESSnfT) 
j  TARGET  (TARGETFILESSTMT) 

)MAXD  :  < INTEGER >  /STMAX/  <ENDCBAR> 

•  «  END  «  /ENDINP/ 

|  <  DCLDESCRIPTION  > 

I  <  BLOCKBEGIN  > 

|  (BLOCKEND) 

S  (OLDFILESTMT) 

•  /ASSINIT/  < ASSERTIONS >  /STRHS/ 

< DCLDESCRIPTION >  : 1  /INTDCL/  /INTMVAR/  /MEMINIT/ 

/SVMEM/  <  DATASPEC  > 

r,  /E( 108  )/  < INTEGER >  /CRDCL/  /INTMVAR/ 

/MEMINIT/  /SVMEM/  < DATASPEC >  ]* 

/STOCL/  (ENDCHAR) 

< DATASPEC >  s:»  <DCLMVAR>  [(  <OCCSPEC>  )]  [  (IS)  ] 

(ATTRSPEC)  /SVDCX/  _ 

<ATTRSPEC>  s <FILE>  /SVP/  /SVPLNM/  <FILEDESC>  < STORAGEDESC > 
/STDEV/ 

|  < RECORD >  /SVR/ 

J  <FIELDSTMT>  /STDPLD/  /SVD/ 

!  [ < GROUP > 3  /SVG/ 

(BLOCKBEGIN)  : BLOCK  /BLKINIT/  [  <NAME>  /SVLBL/  ]  /E( 2 )/  s 

[  <BLOCXSPEC>  1*  /SVBLOK/  <ENDCHAR> 

( BLOCKSPEC >  ; s-  < SOLUTION)  |  < ITERATION)  j  <RELERROR>  _ 

(SOLUTION)  t [  SOLUTION  ]  METHOD  [  (IS)  ]  /E(62>/  (METHODS) 

/SVMETH/  C  -  J 

(METHODS)  : NEWTON  j  GAUSS SEIDEL  j  GS  |  JACOBI 

(ITERATION)  [  (MAXIMUM)  1  (ITER)  [  (IS)  ]  /E(4)/  (NUMBER) 

/SVITER/  [  ,  ] 

(MAXIMUM)  :  MAX  j  MAXIMUM 

(ITER)  s ITER  |  ITERATION  |  ITERATIONS 

(REI£RROR)  : C  RELATIVE  ]  (ERROR)  C  (IS)  ]  /E( 5 )/  (NUMBER) 

/SVERR/  C  <■  J 

(ERROR)  ERR  |  ERROR 

(BLOCKEND)  :  s-  (END)  /BLKEND/  [  <NAME>  /CHKLBL/  ]  (ENDCHAR) 

<END>  :  !»  /ESfDID/ 

(ASSERTIONS  > : : -/E( 14  )/ (CONDITIONAL)  | 

/SVASSR/  /INTMVAR/  (MVAR)  /STMVAR/  /SVCMP1/ 

[ ( IS > /SVNXOP/ ] ( DDLORRHS > 

(CONDITIONAL) :: -IF  /SVAAS1/  /SV0P1/  /SETBIT/  /E( 18 )/ 
<BOOLEANEXPRESSION>  /SVCMP1/  /E(  38 )/ 

THEN  /SVNXOP/  (SIMPLEASSERTION)  /SVNXCMP/ 

[ELSE  /SVNXOP/  (ASSERTION)  /SVNXCMP/]  /RSETIP/  /STALL/ 


239  - 


-  240  - 


< ASSERTION > : :*  /E( 14)/  <CONDITIONAL>  !  <SIMPLEASSERTION) 

<DOLORRHS> : :-/INTODDL/  < DATADESCSTWT >  /FREETMP/ 

|  /E( 33 )/  < INTOAS >  < ASSERTIONS RANCH >  <ENDCHAR> 

< ASSERT IONBRANCH> : <DEFEXPRESSION> 

!  <BOOLEANEXPRESSION>/SVNXCMP/  /STALL/ 
<DEFEXPRESSION> : {  /INTSUB/  <VALUELIST)  )  /FREESUB/ 

<VALUELIST) : (  /CRSUB/  /DECPP/  <VALUELIST)  [ ,  <VALUELIST>  ]*  ) 
/INCPP/ 

|  <OPELEMENT)  /STASS/ 

tOPELEMENT) s [ <SIGN)  /SVOPP/]  < NUMBER >  /STNUM/ 
j  <STRINGFORM> 

< INTOAS >  :  ;-/INTOASS/ 

<SIMPLEASSERTION> : :-/SVASAEl/  /INTMVAR/  <MVAR)  /STMVAR/  /CJCUNIIC/ 

/SVCMP1/  /E( 23 )/  -  /SVNXQP/ 

<  BOOLEANEXPRESSION  >  /SVNXCMP/  /STALL/  <ENDCHAR> 
< SUBVARIABLE> : :»  /SETSUBV/  cVAR>  /SVCTCMV/  /SVCMP1/ 

[(/SVNXDP/  /SETBIT/  /E( 22  )/ 

< BOOLEANEXPRESSION)  /SVNXCMP/  /SVCKSUB/  [, /SVNXDP/ 

< BOOLEANEXPRESSION)  /SVNXCMP/  /SVCXSUB/  ]* 

/E( 24)/  )  ]  /CLCKSUB/  /STALL/ 

<  SUBVARIABLE1 > : /SETSUBV/  <VAR)  /SVCMP1/ 

C(/SVNXOP/  /SETBIT/  /E(22>/ 

< BOOLEANEXPRESSION)  /SVNXCMP/  [, /SVNXDP/ 

<  BOOLEANEXPRESS ION)/ SVNXCMP/ ] * 

/E(24)/  )  ]  /STALL/ 

< BOOLEANEXPRESS ION) : /E( 82  )/  /SVBEXP/  <CONDEXP>  i 

<BOOLEANTERM)  /SVCMP1/ 

C<OR>  /SVNXDP/  <BOOLEANTERM>  /SVNXCMP/]* 
/STALL/ 

<CONDEXP> : :-IF  /SVCOND/  /E( 3  )/  < BOOLEANEXPRESSION)  /SVCMP1/ 

/E( 79  )/  THEN  /SVNXDP/  < BOOLEANEXPRESS ION)  /SVNXCMP/ 

[/E( 12 )/  ELSE  /SVNXDP/  < BOOLEANEXPRESS ION)  /SVNXCMP/] 
/STALL/ 

<OR> : /ORREC/ 

<BOOLEANTERM> : /E( 83  )/  /SVBT1/  < BOOLEAN? ACTOR)  /SVCMP1/ 

[_ /SVNXDP/  <BOOLEANFACTOR>  /SVNXCMP/]* 

/STALL/ 

< BOOLZANF ACTOR) : /E(82)/  /SVBF1/  < CONCATENATION)  /SVCMP1/ 

C  < RELATION)  /SVNXDP/  < CONCATENATION)  /SVNXCMP/]* 
/STALL/ 

<RELATION> : /RELREC/ 

< CONCATENATION) ! /E(84)/  /SVCON/  <ARITHEXP>  /SVCMP1/ 

C  <CONCAT>  /SVNXDP/  <ARITHEXP>  /SVNXCMP/]* 

/STALL/ 

<CONCAT) : /CATREC/ 

<ARITHEXP): /E( 81 )/  /SVAE/  [ <SIGN>  /SVDP1/] 

<TERM>  /SVCMP1/  [<OPS>  /SVNXDP/  <TERM)  /SVNXCMP/]* 
/STALL/ 

«TERM>sj-  /E( 87 )/  /SVTERM/  <FACTOR>  /SVCMP1/ 

C<MOPS>  /SVNXDP/  < FACTOR)  /SVNXCMP/]*  /STALL/ 

<PACTOR>:s-  /E( 85 )/  /SVFAC/  [  /SV0P1/]  < PRIMARY)  /SVCMP1/ 

[<EXPON>  /SVNXDP/  < PRIMARY)  /SVNXCMP/]*  /STALL/ 

<EXPON>  s /EXPREC/ 

< PRIMARY) : /E( 86  )/  /SVPRIM/  <ISPRIM>  /SVCMP1/  /STALL/ 

<ISPRIM)::-  (  < BOOLEANEXPRESSION)  /E(24)/  ) 
j  < NUMBER)  /STNUM/ 

|  <STRINGPORM> 

|  <FUNCTIONCALL) 

|  < SUBVARIABLE 1> 

<STRINGFORM> : >  /SETSTRN/  [  < STRING)  /SVSTRNG/1 

/E( 26  )/ 

•  /ADLEX/  [B  /STBIT/  /E(l)/  <BSUFX)]  /STNUM/ 
<FUNCTIONCALL> : <  FUNCTIONNAME  >  /STFUN/ 

/SETFUNC/  [(/SVNXDP/  < BOOLEANEXPRESSION) 

/SVNXCMP/  [, /SVNXDP/  < BOOLEANEXPRESSION) 

/SVNXCMP/  ]*  )  ]  /STALL/ 


<FUNCTIONNAME> : :■  /FNCHECK/ 

cMVAR) : (  < SUBVARIABLE >  /SVMVAR/ 

[,  < SUBVARIABLE >  /SVMVAR/  ]*  /E(24)/  ) 

!  < SUBVARIABLE >  /SVMVAR/ 

<VAR> : /SETVAR/  /INITQNM/  /E( 68 )/  <NAME>  /ADLEX/  /MKQNM/ 

[ .  /ADLEX/  /E( 68 )/  <NAME>  /ADLEX/  /MKQNM/]*  /STRCON/ 
(DCLMVAR)  (  <VAR>  /SVCKMV/  /SVMVAR/ 

C,  <VAR>  /SVCKMV/  /SVMVAR/  ]*  ) 

1  <VAR>  /SVCKMV/  /SVMVAR/ 

<BSUFX>  s /BITSTR/ 

<QNAME> : /INITQNM/  /E(68)/  <NAME>  /MKQNM/ 
c  .  /E( 68 )/  <NAME>  /MKQNM/  ]  * 

< STRING) : <STRINGCONST> 

<OPS>:!«  /OPREC/ 

<MOPS>  s /MOPREC/ 

<TEST> : :  —  /TESTBIT/ 

<MODULENAMESTMT> : 5-  /E(63)/s  /E(64)/  <NAME> 

/STMOD/  <ENDCHAR> 

<SOURCEFILESSTWT>  :  :  =  C  <FILEKEIWORD)  ]  /E(  75  )/  /INITSFL/  : 

<SOURCEFILELIST>  /STSRC/  <ENDCHAR> 

<FILEKEYWORD> : : -FILES | FILE 

<SOURCEFILELIST> : /E( 76  )/  <NAME>  /SVSRC/ 

[,  /E( 76 )/  <NAME>  /SVSRC/]* 

<TARGETFILESSTMT> : [(FILEKEYWORD) ]  /E( 77 )/  /INITTFL/  : 

<TARGETFILELIST>  /STTAR/  <ENDCHAR> 

(TARGETFILELIST)::-  /E(78)/  <NAME>  /SVTAR/ 

C,  /E( 78 )/  <NAME>  /SVTAR/  ]* 
c  DATADESCSTMT  > : <  DATADESCRIPTION  )  (ENDCHAR) 

<  DATADESCRIPTION  > : 

<FILESTMT>  /STPILE/ 

J <RECORDSTMT>  /STREC/ 

| <  GROUP  STMT)  /STGRP/ 

|  <FIELDSTMT>  /STFLD/ 

] <SUBST*W>  /STSUBST/ 

(SUBSTMT) : :-<SUBSCRIPT>/MEMINIT/  /SVMEM/  [(  <OCCSPEC>  )J 
< SUBSCRIPT) : SUB  j  SUBSCRIPT  |  SUBSCRIPTS 
<FII£>::-  FILE  •  REPORT  |  FILES  |  REPORTS 
<RECORDSTMT> : < RECORD)  /MEMTNIT/  C(  ]  <ITEMLIST>  [ )] 

< RECORD)  : REC  |  RECORD  |  RECORDS 
(ITEMLIST) : /E(52)/(ITEM>  CCO  <ITEM>]* 

<ITEM>; :-<NAME>  /SVMEM  /  C  •  <NAME>  /SVMEM/  ]*  [(  <OCCSPEC>  )] 
<OCCSPEC> : <STAR>  /SVSTAR/  |  cMINOCC)/SVMNOC/  [ (MAXDCC) ] 

<STAR> : /STARREC/ 

<MINOCC> : :-< INTEGER) 

<MAXDCC>  [ :/E< 51 )/]< INTEGER)  /SVMXDC/  /CKMNMX/ 

j  < INTEGER)  /SVMXDC/  /CKMNMX/ 

<GROUPSTMT> : < GROUP )/MEMINIT/  [(  ]  <ITEMLIST>  [ )] 

< GROUP)  : GRP  !  GROUP  |  GROUPS 
<FIELDSTMT>: <FIELD>  /SVFLD/  < FIELD  ATTR) 

[<ONCND>  CO  /E(  112  )/<OPT>/SVOP/] 
cONCND)  : ONCNVERR  |  ONCERR 
<OPT)  s STOP  |  <BINORNUM> 

(BINORNUM)  ss-  * /E( 110 )/ <BIN> ' B/E( 111 )/  (CXBIN) 
j  [(SIGN)  /SVS/]  < NUMBER) 

<CKBIN)  :: -/CXBIN/ 

< FIELD)  : FLD  |  FIELD  j  FIELDS 
<FIELDATTR>; [( ]  <TIPE>  /SVFETP2/C  <LENGSPEC>] 

[,]  [<LINESPEC>]  [,]  [ <COLSPEC) ]  f  )] 

<LENGSPEC)  s:-  (  /E(  48 )/  <MINtJENGTH>  f  <MAXLENGTH)  ]  /E<49)/  ) 

| <MINLENGTH)  [ (MAXLENGTH) ] 
cMINLENGTH) : « INTEGER)  /SVMNFLN/ 

<LINESPEC> : :  —  LINE  /E(53)/  /E(54)/  /E( 55 )/  (< INTEGER)  /SVLINE/ ) 
<COLSPEC> : COL  /E(90)/  /E( 91 )/  /E( 92 )/  (< INTEGER)  /SVCOL/ ) 

<TVPE) : : *  /E(  47 )/  <PICDESC)  j  <STRINGSPEC)  j  <NUMSPEC)  !  < GENERIC 
(GENERIC)  : <GEN>  /SVGEN/ 

<GEN)  : GENERIC  |  GEN 
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<PICDESC>t :-  <PICTYPE>  /E< 67 )/  /SVPIC/  *  [  <STRING>  /SVPICST/  )  * 
/STPIC/ 

<PICTYPE>: :»  PIC  !  PICTURE 
<STRINGSPEC) : <  STRINGTYPE  >  /SVSTRTP/ 

<STRINGTYPE)  s  :-  CHAR  j  CHARACTER  !  BIT  |  NUM  |  NUMERIC 
<NUMSPEC>:s-  <NUMTYPE>  /SVNUMTP/  [  <FIXFLT)  /SVMOD/  ] 

<NUMTYPE)s:-  BIN  i  BINARY  j  DEC  |  DECIMAL 
<FIXFLT>::-  FIX  !  FIXED  |  FL  |  FLOAT  |  FLT 
<MAXLENGTH> : :»  [:]  <INTEGER>  /SVMXFLN/ 

j  ,  /E( 46 )/  «SINTGR>  /SVSCALE/ 

|  <  INTEGER*  /SVMXFLN/ 

<SINTGR> : :-  -  /E( 50 )/  «INTEGER>  /NEGATE/  }  < INTEGER* 

< NUMBER)  /SETNUM/  <INITNUM>  /E( 65  )/  <RECNUM> 

<RECNUM> : /RECNUM/ 

<BIN>  : /BIN/ 

<INITNUM>  :  /INITNUV 

<SIGN>  :  s-  +  - 

<RECG> : :  —  < RECORD >  j  < GROUP) 

<KEY> : : -KEY  j SEQUENCE 
<CODE> : : -EBCDIC | BCD | ASCII 
<ANY)  s :-  <NAME> j  < INTEGER) 

<NOTRK S> : 7|9 

<DENSITY>  s 200 | 556 ! 800 | 1600 | 6250 
< PARITY) : :-  ODD j EVEN 

<TYPEDSK> : 2314! 2311 ! 3330) 2305  !  3330-1 
<ORG> : : -OR G | ORGANIZATION 

<ORGTYPE>  :  /E(  7  )/ ISAM!  SEQUENTIAL  jSAM|  INDEXEDSEQUENTIAL  |  POST  {MAIL 

<ENDCHAR>s:-  /E(74)/  <ENDCHAR>  /STMTINC/ 

<ENDCHAR> : :—  /SVENDC/  .  • 

<  STRINGCONST  > : :-/CHARSTR/ 

<NAME> : S-/NAMEREC/ 

< INTEGER) s  J-/INTREC/ 

<IS>  s IS  !  -  !  ARE 

<FILESTMT>s  j-  «FII£>  /SVFI2QV  /MEM1NIT/  <SONDESC> 

<FILEDESC)  < STORAGEDESC >  /STDEV/ 

<SONDESC>: :-(  <ITEMLIST>  ) 

!  <RECG)  [NAME]  [<IS)]  [( ]  <ITEM>  [)] 

<OLDPILESTMT) : «FILE>  [NAME]  C<IS>]  /E(56)/  /MEMINIT/  /INTMVAR/ 

<DCIMVAR>  /SVFLNM/ 

<RECG)  [NAME]  [<IS>]  [(]  <ITEM>  [)] 

<FILEDESC>  /STFILE/ 

< STORAGEDESC )  /STDEV/  <ENDCHAR> 

<FILEDESC> : :—  [STORAGE  [NAME]  [<IS)]  /E(44)/  <NAME)  /SVSTNM/] 

[ <KEY>  [NAME]  [<IS>]  /E( 45 )/  <NAME>  /SVKEY/) 

[ <ORG>  [<IS)]  <ORGTYPE>  /SVORG3/] 

< STORAGEDESC )  : :-  [DEVICE  [ <IS> ]  < DEVICE) ]  /SVDEV/ 

[RECORD  /E( 57)/] [FORMAT  [<IS>]  tRECFMT) J/SVRECF/ 

<BLKRECVOL) 

[ <TAPEDESC) ]  [ <DISKDESC) ] 

[HARDWARE]  [SOFTWARE] 

< DEVICE)  : s—  /E(61)/  TAPE  !  DISK/SETDEVB/ 

!  CARD  /SETDEVC/  i  PRINTER  /SETDEVP/ 

!  PUNCH  /SETDEVU/  j  TERMINAL  /SETDEVT/ 

<RECFMP>  : s—  /E( 69 )/  FIXED | VARIABLE  j  VARSPANNED j  UNDEFINED 
<BLKRECVOL)  ! 

[  [MAX]  /E(70)/  /E( 71 )/  BLOCKS I ZE  [<IS>]  < INTEGER)  /SVBLK/  ) 
[  [MAX/E( 59 )/]  RECORDS I ZE  [<IS)]  /E( 72  )/< INTEGER >/SVRCSZ/] 
[VOLUME  [NAME]  [<IS>]  /E(  60  )/  <NAME>/SWOL/  [  ,/E(  60  >/<NAME)  ]*  ] 
<TAPEDESC)  [ <TRACXS)  [<IS)]  /E( 66 )/<N0TRKS)/SVTRK2/  ] 

[PARITY  [<IS>]  /E( 66 )/  <PARITY)/SVPAR2/] 

[DENSITY  [<IS>]  /E( 66  )/  < DENSITY)  /SVDEN2/] 

[  [TAPE]  LABEL  [<IS)]  < LABELTYPE > /SVLAB2/ ] 

[START  [FILE]  [ < IS) ]  /E(66)/  < INTEGER)  /SVSTFL2/] 

[ [CHAR]  CODE  [<IS>]  <CODE>  /SVCC/  ] 

< TRACKS)  : :-  NOTRKS  |  TRACKS 

< LABELTYPE)  : /E( 58 )/  IBMSTDI ANSISTD! NONE ! BYPASS 


<DISKDESC> 


: [UNIT  C<IS>]  /E( 9  )/  <TYPEDSK>  /SVUNIT2/ ] 

[ < CYLINDERS >/SVUCYL/  [<IS>]  /E( 66 )/  < INTEGER) 
/SVQTY2/ ] 

< CYLINDERS >  : NOCYLS  |  CYLINDERS 

<HARDWARE> s [[COMPUTER]  MODEL  [<IS>]  <ANY> 

< SOFTWARE) : [[OPERATING]  SYSTEM  [<IS>]  <ANY>  ] 


[■ 
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APPENDIX  C 

WARNING  AND  ERROR  MESSAGES  GENERATED  BY  THE  CONFIGURATOR 


Cl.  ERROR/WARNING  MESSAGES  FOR  SYNTAX  ANALYSIS: 


l.*WARNG*  ( LEX1 ) 


2 .  *ERROR* 

3 .  * ERROR* 

4 .  *ERROR* 

5 .  *ERROR* 

6 .  *ERROR* 

7 .  *ERROR* 

8 .  *ERROR* 

9 .  *ERROR* 

10 .  *ERROR* 

11 .  *ERROR* 

12 .  *ERRQR* 

13 .  *ERRQR* 


(LEX2) 
(LEX3 ) 
(LEX4) 
( SAP1 ) 
( SAP2 ) 
( SAP3 ) 
(SAP4) 
( SAP5 ) 
( SAP6  ) 
(SAP7) 
(SAPS) 
( SAP9 ) 


14 . *ERROR*  (SAP10 


15 .  *ERROR* 

16 .  *ERROR* 


(SAP11 
( SAP12 


THE  IDENTIFIER  "text . .  . "  IS  TRUNCATED  TO  10 
CHARACTERS. 

THE  LAST  STATEMENT  DOES  NOT  TERMINATE  WITH  "*/". 

THE  LAST  STATEMENT  DOES  NOT  TERMINATE  WITH  " 
CANNOT  FIND  THE  NAMED  CONFIGURATION  INPUT  FILE. 
MISSING  * ; *  AT  END  OF  A  STATEMENT.  STMT:  stmt# 
ILLEGALLY  STRUCTURED  NAMES  FOUND.  STMT:  stmt* 
ILLEGALLY  STRUCTURED  STATEMENT.  STMT:  Stmt# 

MISSING  AFTER  'F1  OR  'M' .  STMT:  Stmt* 

ILLEGAL  NAME.  STMT:  Stmt* 

ILLEGAL  FILE  ORGANIZATION.  STMT:  stmt# 

RECORD  SIZE  MUST  BE  AN  INTEGER! .  STMT:  Stmt# 

VERSION  NUMBER  MUST  BE  AN  INTEGER! .  STMT:  Stmt# 
ILLEGAL  NAME  FOUND  IN  A  SYNONYM  STATEMENT. 

STMT:  stmt# 

)  MISSING  ' , '  IN  BETWEEN  TWO  NAMES  IN  A  SYNONYM 
STATEMENT .  STMT :  Stmt# 

)  MISSING  TAGET  NAME  OF  AN  ARROW  IN  A  PATH  STATEMENT 
)  ILLEGAL  KEYWORD.  EXPECT:  "TYP" , "ORG" ,  OR  "TYPE" 


C2 .  ERROR/WARNING  MESSAGES  FOR  CONFIGURATION  GRAPH  CONSTRUCTION: 
17.  *ERROR*( CNF1 )  THE  SYNONYM  NAMES  HAVE  NO  PHYSICAL  NAME  DEFINED: 


18. 


-  . . .NAME. 

.  .  .ORG. 

. RECSZ .  . . FULLPHYSICALNAME . 

namel 

orgl 

rec. sizel 

pnamel 

name  2 

org2 

rec.size2 

pname2 

name  3 

org3 

rec.si.ze3 

pname3 

*ERROR*( CNF2 )  CONFLICT 

ATTRIBUTEf  S ) 

FOUND  FOR  SYNONYM 

-  . . .NAME. 

.  .  .ORG. 

. RECSZ .  . . FULLPHYSICALNAME . 

namel 

orgl 

rec. sizel 

pnamel 

name  2 

org2 

rec . size2 

pname2 

name  3 

org3 

rec. size 3 

• 

• 

pname3 

19 .  *ERROR*( CNF3 )  AN  M->M  PATTERN  FOUND  IN  LINE:  Stmt  no 

20 .  *ERROR*( CNF4 )  A  MODULE  NAME  CANNOT  BE  SUFIXED, 

ILLEGAL  NAME :  name 

21 .  *ERROR*( CNF5 )  ILLEGAL  MODULE  NAME.  THE  NAME  HAS  BEEN  USED 

FOR  A  FILE,  name 

22 .  *ERROR*( CNF6 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 
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MODULE:  name,  THE  CONFILICTING  PHYSICAL  NAMES: 
namel,name2,  STMT:  stmt# 

23. *ERRQR*(CNF7)  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name.  THE  CONFILICTING  LOCATIONS: 
locationl , location 2 ,  STMT :  stmt# 

24.  "ERROR* ( CNF8 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name,  THE  CONFILICTING  DEVICES: 
devicel , device2 , STMT :  stmt# 

25 .  *ERROR*( CNF9 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name.  THE  CONFILICTING  DIRECTORIES: 
directoryl,directory2,STMr:  stmt* 

26 .  *ERROR*( CNF10 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name.  THE  CONFILICTING  SUFIXES: 
sufixl , suf 1x2 , STMT :  stmt* 

27 .  * ERROR* ( CNF 11 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name.  THE  CONFILICTING  VERSIONS: 
version! ,  version2,  STMT:  stmt* 

28 .  * ERROR *( CNF 12 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name.  THE  CONFILICTING  ORGANIZATIONS: 
orgl , org2 , STMT :  stmt* 

29 .  *ERROR*( CNF 13 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

MODULE:  name.  THE  CONFILICTING  STATUSES: 
statusl,  status2,  STMT: stmt* 

30 .  'ERROR* ( CNF14 )  ILLEGAL  FILE  NAME.  THE  NAME  HAS  BEEN  USED  FOR  A 

MODULE:  name,  STMT:  stmt* 

31 .  'ERROR* ( CNF15 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  PHYSICAL  NAMES: 
pnamel , pname2 ,  STMT :  stmt* 

32 .  'ERROR* ( CNF16 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  LOCATIONS: 
locationl , locat ion2 , STMT :  stmt* 

33 .  *ERRDR*( CNF17  )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  DEVICES: 
devicel, device2,  STMT:  stmt* 

34.  *ERROR*(  CNF  18  )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  DIRECTORIES: 
directoryl,  directory2,  STMT:  stmt* 

35 .  *ERROR*( CNF19 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  SUFIXES: 
su£ixl,  suf  1x2,  STMT:  stmt* 

36 .  'ERROR* ( CNF20 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND 

FOR  FILE:  name.  THE  CONFILICTING  VERSIONS: 
versionl,  version2,  STMT:  stmt* 

37 .  * ERROR* ( CNF 21 )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  ORGANIZATIONS: 
orgl,  org2,  STMT:  stmt* 

38 .  *ERRQR*( CNF22  )  A  REDUNDANT  AND  CONFILICTING  STATEMENT  FOUND  FOR 

FILE:  name.  THE  CONFILICTING  RECORD  SIZES: 
rec.sizel,  rec.size2,  STMT:  stmt* 

39 .  *WARNG*( CNF23  )  PHYSICAL  NAME  TYPE  LENGTH  EXCEEDS  3  (type). 

40 .  *ERHQR*( CNF24 )  UNDEFINED  NAME  FOUND  IN  A  SYNONYM  STATEMENT: 

name ,  STMT :  stmt 

41 .  •ERROR* ( CNF26 )  ILLEGAL  SYNONYM  STATEMENT  (NO  DEFINED  SYMBOL 

HAS  BEEN  FOUND).  STMT:  Stmt* 

42 .  'ERROR* ( CNF 2 7 )  DIFFERENT  NODE  TYPES  SPECIFIED  FOR  SYNONYM  NAMES 

.  . . . NAME ...  . TYPE . 

namel  typel 
name2  type2 


43  .  'ERROR* (  CNF  2  8  ’)  WRONG  STATEMENT  ORDER.  NO  PATH  STATEMENT 
CAN  BE  PLACED  AFTER  SYNONYM(S). 


C3 .  ERROR/WARNING  MESSAGES  DURING  COMPLETENESS  ANALYSIS 
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44 .  * ERROR*  (CMP1)  AN  ISOLATED  PILE  NODE  POUND:  name 

45 .  *WARNG'  ( CMP2  )  INCOMPLETE  DEFINITION  POUND  FOR  A 

"MAIL"  OR  "POST"  PILE:  name 

46 .  * ERROR*  (CMP 3 )  MORE  THAN  ONE  PRODUCER  POUND  FOR  A  POST 

FILE :  name 

47 .  *ERROR*  ( CMP4 )  MORE  THAN  ONE  PRODUCER  POUND  FOR  A  SAM 

PILE :  name 

48 .  * ERROR*  ( CMP5 )  AN  ISOLATED  MODULE  NODE  POUND:  name 

49 .  •ERROR'*  ( CMP6 )  MORE  THAN  ONE  PRODUCER  OR  CONSUMBER 

POUND  FOR  A  "MAN"  MODULE:  name 

50 .  * ERROR*  ( CMP7 )  A  "MAN"  MODULE  MUST  COMMUNICATE  WITH 

"MAIL"  FILES,  (name) 

51 .  * ERROR*  (CMP9)  THE  PILE( S  )  CONSUMED  OR  PRODUCED  BY 

MODULE:  name  ARE  NOT  CO-LOCATED. 


C4.  ERROR/WARNING  MESSAGES  DURING  SCHEDULING  AND  DOCUMENTATION 
GENERATION 

52 .  * ERROR*  (RPT2)  MORE  THAN  ONE  PRODUCER  POUND  FOR  A  SEQ 

pile  "name". 

53. *WARNG*  (RPT3 )  MORE  THAN  ONE  CONSUMER  POUND  FOR  A  SEQ 

PILE  "name".  THEY  ARE  SCHEDULED  SEQUENTIALLY. 

54.  'ERROR*  (RPT5 )  MORE  THAN  ONE  CONSUMER  POUND  FOR  A  MAIL 

PILE  "name". 

55 .  'ERROR*  (RPT6)  MORE  THAN  ONE  PRODUCER  POUND  FOR  A  POST 

PILE  "name". 

56 .  'WARNG*  ( RPT7 )  A  MULTI-NODE  MAXIMALLY  STRONGLY  CONNECTED 

COMPONENT  POUND  IN  CONFIGURATION  CONSISTS  OP: 

-  element  namel 

-  element  name2 


THE  PILE  NODES  MUST  HAVE  A  VIRTUAL  DIMENSION. 

57 . 'ERROR'  (SEQ1)  A  MAXIMALLY  STRONGLY  CONNECTED 
COMPONENT  CONTAINS  SEQUENTIAL 
EDGES: 

-  Component  l:  elel<SEQ>,  ele2,  ... 

-  Component  2:  elel,  ele2<SEQ>,  ... 

-  Component  3:  elel,  ele2,  ... 


58 . *ERROR*  (SCD1)  CYCLES  POUND  IN  A  SCHEDULE  GRAPH 
CONSISTING  OP: 

-  PAR  NODE:  elel,  ele2<SEQ>, . . . 

-  PAR  NODE:  elel,  ele2, . . . 

-  PAR  NODE:  elel<SEQ>,  ele2, . . . 
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Note. 

Every  message  is  associated  with  a  unique  code  which  is  used  to 
identify  the  producer  of  the  message.  The  following  list  shows  the 
correspondence  between  the  codes  and  programs. 


Code 

Program  name 

Description 

CNF 

CONF 

Main  Controler 

LEX 

LEX 

Lexical  Analyzer 

SAP 

SAP 

Syntax  Analyzer 

CMP 

CMP ANA 

Completeness  Checking 

SEQ 

SEQCX 

Consistency  Checking 

SCD 

SCHEDULE 

Scheduling 

RPT 

GRPT 

Documentation 
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